Tipos de almacenamiento de archivos

Elija el tipo de File Storage for Classic que desea suministrar.

Clases de almacenamiento bronce, plata y oro

Estas clases de almacenamiento proporcionan almacenamiento resistente. El almacenamiento resistente le permite elegir el tamaño del almacenamiento en gigabytes en los niveles de IOPS predefinidos.

Clase de almacenamiento personalizada

Esta clase de almacenamiento proporciona almacenamiento de rendimiento. Con el almacenamiento de rendimiento, tiene más control sobre el tamaño del almacenamiento y de IOPS.

IOPS

Elija el tamaño e IOPS para el File Storage for Classic. El tamaño y el número de IOPS definen el número total de IOPS (operaciones de entrada/salida por segundo), lo que sirve como indicador de la rapidez del almacenamiento. Cuantas más IOPS tenga el almacenamiento, más rápido se procesarán las operaciones de entrada y salida.

Clases de almacenamiento bronce, plata y oro

Estas clases de almacenamiento incluyen un número fijo de IOPS por gigabyte y se suministran en discos duros SSD. El número total de IOPS depende del tamaño del almacenamiento que elija. Puede seleccionar cualquier número entero de gigabytes comprendido dentro del rango de tamaño permitido, como por ejemplo 20 Gi, 256 Gi o 11854 Gi. Para determinar el número total de IOPS, debe multiplicar IOPS por el tamaño seleccionado. Por ejemplo, si selecciona un tamaño de File Storage for Classic de 1000 Gi en la clase de almacenamiento de plata que se suministra con 4 IOPS por GB, el almacenamiento tendrá un total de 4000 IOPS.

Clase de almacenamiento personalizada

Cuando selecciona esta clase de almacenamiento, tiene más control sobre el tamaño y las IOPS que desea. Para el tamaño, puede seleccionar cualquier número entero de gigabytes comprendido dentro del rango de tamaño permitido. El tamaño que elija determina el rango de IOPS que tendrá a su disponibilidad. Puede elegir un tamaño de IOPS que sea un múltiplo de 100 y que esté en el rango especificado. Las IOPS que elige son estáticas y no se escalan con el tamaño del almacenamiento. Por ejemplo, si elige 40 Gi con 100 IOPS, el número total de IOPS seguirá siendo 100.

La proporción entre IOPS y gigabytes también determina el tipo de disco duro que se suministra. Por ejemplo, si tiene 500 Gi a 100 IOPS, la proporción entre IOPS y gigabyte será de 0,2. Si la proporción es menor o igual a 0,3, el almacenamiento se suministra en discos duros SATA. Si la proporción es mayor que 0,3, el almacenamiento se suministran en los discos duros SSD.

Política de reclamación

Decida si desea conservar los datos después de que se suprima el clúster o la reclamación de volumen persistente (PVC).

• Si desea conservar los datos, seleccione la clase de almacenamiento retain. Cuando se suprime la PVC, únicamente ésta se suprime. El PV, el dispositivo de almacenamiento físico de la cuenta de infraestructura de IBM Cloud y los datos seguirán existiendo. Para reclamar el almacenamiento y volverlo a utilizar en el clúster, debe eliminar el PV y seguir los pasos de utilización de File Storage for Classic existente.
• Si desea que el PV, los datos y el dispositivo físico de File Storage for Classic se supriman cuando suprima la PVC, elija una clase de almacenamiento sin la opción retain.

Tipo de facturación

Elija por horas o por meses. Revise los precios para obtener más información.

De forma predeterminada, todos los dispositivos de File Storage for Classic se suministran con un tipo de facturación por hora.

Si selecciona el tipo de facturación mensual, cuando elimine el almacenamiento persistente seguirá pagando el cargo mensual por el mismo, aunque solo lo haya utilizado durante un breve periodo de tiempo.

Preparación del almacenamiento existente

Antes de empezar a montar el almacenamiento existente en una app, debe recuperar toda la información necesaria para su PV y debe preparar el almacenamiento para que el clúster pueda acceder al mismo.

Para el almacenamiento que se aprovisionó con una clase de almacenamiento " retain ".

Si ha suministrado almacenamiento con la clase de almacenamiento retain y elimina la PVC, el PV y el dispositivo de almacenamiento físico no se eliminan de forma automática. Para volver a utilizar el almacenamiento en el clúster, primero debe eliminar el PV restante.

Para utilizar el almacenamiento existente en un clúster distinto de aquel en el que se ha suministrado, siga los pasos para almacenamiento que se ha creado fuera del clúster para añadir el almacenamiento a la subred del nodo trabajador.

1. Obtenga una lista de los PV existentes.

   oc get pv
   

   Busque el PV perteneciente a su almacenamiento persistente. El PV está en el estado released.

2. Obtenga los detalles del PV.

   oc describe pv <pv_name>
   

3. Anote los valores de CapacityGb, storageClass, failure-domain.beta.kubernetes.io/region, failure-domain.beta.kubernetes.io/zone, server y path.

4. Elimine el PV.

   oc delete pv <pv_name>
   

5. Verifique que el PV se ha eliminado.

   oc get pv
   

Para el almacenamiento persistente que se aprovisionó fuera del clúster

Si desea utilizar el almacenamiento existente que suministró anteriormente, pero que nunca utilizó en su clúster, debe hacer que el almacenamiento esté disponible en la misma subred que sus nodos trabajadores.

1. En el portal de infraestructura deIBM Cloud, haga clic en Almacenamiento.
2. Pulse File Storage for Classic y, en el menú Acciones, seleccione Autorizar host.
3. Seleccione Subredes.
4. En la lista desplegable, seleccione la subred VLAN privada a la que está conectado el nodo trabajador. Para buscar la subred del nodo de trabajador, ejecute ibmcloud oc worker ls --cluster <cluster_name> y compare el valor Private IP del nodo de trabajador con la subred que ha encontrado en la lista desplegable.
5. Pulse Enviar.
6. Pulse el nombre del File Storage for Classic.
7. Anote los valores de los campos Mount Point, size y Location. El campo Mount Point se visualiza como <nfs_server>:<file_storage_path>.

Creación de un volumen persistente y de una reclamación de volumen persistente

1. Cree un archivo de configuración de almacenamiento para el PV. Incluya los valores que ha recuperado anteriormente.

   apiVersion: v1
   kind: PersistentVolume
   metadata:
    name: mypv
    labels:
       failure-domain.beta.kubernetes.io/region: <region>
       failure-domain.beta.kubernetes.io/zone: <zone>
   spec:
    capacity:
      storage: "<size>"
    accessModes:
      - ReadWriteMany
    nfs:
      server: "<nfs_server>"
      path: "<file_storage_path>"
   

   name

   Especifique el nombre del objeto de PV que crear.

   labels

   Especifique la región y la zona que ha recuperado anteriormente. Debe tener al menos un nodo de trabajador en la misma región y zona.

   storage

   Especifique el tamaño de almacenamiento del recurso compartido de archivos NFS existente que ha recuperado anteriormente. El tamaño de almacenamiento se debe especificar en gigabytes, por ejemplo, 20Gi (20 GB) o 1000Gi (1 TB), y el tamaño debe coincidir con el tamaño del recurso compartido de archivos existente.

   accessMode

   Especifique una de las opciones siguientes.

   • ReadWriteMany: Varios pods pueden montar la PVC. Todos los pods pueden leer y escribir en el volumen.
   • ReadOnlyMany: Varios pods pueden montar la PVC. Todos los pods tienen acceso de sólo lectura.
   • ReadWriteOnce: Solo un pod puede montar la PVC. Este pod puede leer y escribir en el volumen.

   server

   Escriba el ID del servidor de recursos compartidos de archivos NFS que ha recuperado anteriormente.

   path

   Especifique la vía de acceso al recurso compartido de archivos NFS existente que ha recuperado anteriormente.

2. Cree el PV en el clúster.

   oc apply -f mypv.yaml
   

3. Verifique que se ha creado el PV.

   oc get pv
   

4. Cree otro archivo de configuración para crear la PVC. Para que la PVC coincida con el PV que ha creado anteriormente, debe elegir el mismo valor para storage y accessMode. El campo storage-class debe ser una serie vacía. Si alguno de estos campos no coincide con el PV, entonces se aprovisiona dinámicamente un nuevo PV y una nueva instancia de almacenamiento físico.

   kind: PersistentVolumeClaim
   apiVersion: v1
   metadata:
     name: mypvc
   spec:
     accessModes:
      - ReadWriteMany
     resources:
       requests:
         storage: "<size>"
     storageClassName: ""
   

5. Cree la PVC.

   oc apply -f mypvc.yaml
   

6. Verifique que la PVC se ha creado y se ha vinculado al PV.

   oc describe pvc mypvc
   

   Salida de ejemplo

   Name: mypvc
   Namespace: default
   StorageClass:    ""
   Status: Bound
   Volume: pvc-0d787071-3a67-11e7-aafc-eef80dd2dea2
   Labels: <none>
   Capacity: 20Gi
   Access Modes: RWX
   Events:
       FirstSeen LastSeen Count From        SubObjectPath Type Reason Message
       --------- -------- ----- ----        ------------- -------- ------ -------
       3m 3m 1 {ibm.io/ibmc-file 31898035-3011-11e7-a6a4-7a08779efd33 } Normal Provisioning External provisioner is provisioning volume for claim "default/my-persistent-volume-claim"
       3m 1m     10 {persistentvolume-controller } Normal ExternalProvisioning can't find provisioner "ibm.io/ibmc-file", expecting that a volume for the claim is provisioned either manually or via external software
       1m 1m 1 {ibm.io/ibmc-file 31898035-3011-11e7-a6a4-7a08779efd33 } Normal ProvisioningSucceeded    Successfully provisioned volume pvc-0d787071-3a67-11e7-aafc-eef80dd2dea2
   

Ha creado correctamente un PV y lo ha enlazado a una PVC. Ahora los usuarios del clúster pueden montar la PVC en sus despliegues y empezar a leer el objeto de PV y a escribir en el mismo.

Creación de la PVC al crear un conjunto con estado utilizando suministro dinámico

Utilice esta opción si desea crear automáticamente la PVC al crear el conjunto con estado.

Antes de empezar: acceda al clúster de Red Hat OpenShift.

1. Verifique que todos los conjuntos con estado existentes del clúster estén totalmente desplegados. Si todavía se está desplegando un conjunto con estado, no puede empezar a crear el conjunto con estado. Debe esperar a que todos los conjuntos con estado del clúster se hayan desplegado por completo para evitar resultados inesperados. Obtenga una lista de los conjuntos con estado existentes en el clúster.

   oc get statefulset --all-namespaces
   

   Salida de ejemplo

   NAME              DESIRED   CURRENT   AGE
   mystatefulset     3         3         6s
   

2. Visualice el estado de los pods de cada conjunto con estado para asegurarse de que el despliegue del conjunto con estado haya finalizado.

   oc describe statefulset <statefulset_name>
   

   Salida de ejemplo

   Name:               nginx
   Namespace:          default
   CreationTimestamp:  Fri, 05 Oct 2022 13:22:41 -0400
   Selector:           app=nginx,billingType=hourly,region=us-south,zone=dal10
   Labels:             app=nginx
   billingType=hourly
   region=us-south
   zone=dal10
   Annotations:        oc.kubernetes.io/last-applied-configuration={"apiVersion":"apps/v1","kind":"StatefulSet","metadata":{"annotations":{},"name":"nginx","namespace":"default"},"spec":{"podManagementPolicy":"Par..."
   Replicas:           3 desired | 3 total
   Pods Status:        0 Running / 3 Waiting / 0 Succeeded / 0 Failed
   Pod Template:
   Labels:  app=nginx
   billingType=hourly
   region=us-south
   zone=dal10
   

   Un conjunto con estado se ha desplegado por completo cuando el número de réplicas que encuentra en la sección Replicas de la salida de CLI es igual al número de pods con el estado Running en la sección Pods Status. Si un conjunto con estado aún no se ha desplegado por completo, espere hasta que el despliegue haya finalizado antes de continuar.

3. Cree un archivo de configuración para el conjunto con estado y el servicio que utiliza para exponer el conjunto con estado.

   Ejemplo de conjunto con estado que especifica una zona. En el ejemplo siguiente se muestra cómo desplegar NGINX como un conjunto con estado con 3 réplicas. Para cada réplica, se proporciona un dispositivo de File Storage for Classic de 20 gigabytes en función de las especificaciones de la clase de almacenamiento ibmc-file-retain-bronze. Todos los dispositivos de almacenamiento se suministran en la zona dal10. Dado que no se puede acceder a File Storage for Classic desde otras zonas, todas las réplicas del conjunto con estado también se despliegan en los nodos de trabajador que se encuentran en dal10.

   apiVersion: v1
   kind: Service
   metadata:
     name: nginx
     labels:
       app: nginx
   spec:
     ports:
     - port: 80
       name: web
     clusterIP: None
     selector:
       app: nginx
   ---
   apiVersion: apps/v1
   kind: StatefulSet
   metadata:
    name: nginx
   spec:
     serviceName: "nginx"
     replicas: 3
     podManagementPolicy: Parallel
     selector:
       matchLabels:
         app: nginx
         billingType: "hourly"
         region: "us-south"
         zone: "dal10"
     template:
       metadata:
         labels:
           app: nginx
           billingType: "hourly"
           region: "us-south"
           zone: "dal10"
       spec:
         containers:
         - name: nginx
           image: k8s.gcr.io/nginx-slim:0.8
           ports:
           - containerPort: 80
             name: web
           volumeMounts:
           - name: myvol
             mountPath: /usr/share/nginx/html
       volumeClaimTemplates:
       - metadata:
          name: myvol
         spec:
          accessModes:
          - ReadWriteOnce
          resources:
            requests:
              storage: 20Gi
              iops: "300" #required only for performance storage
          storageClassName: ibmc-file-retain-bronze
   

   Ejemplo de conjunto con estado con una regla de antiafinidad y una creación de File Storage for Classic demorada. En el ejemplo siguiente se muestra cómo desplegar NGINX como un conjunto con estado con 3 réplicas. El conjunto con estado no especifica la región y la zona en las que se ha creado el File Storage for Classic. En su lugar, el conjunto con estado utiliza una regla de antiafinidad para asegurarse de que los pods se distribuyen entre nodos trabajadores y zonas. La antiafinidad de los nodos trabajadores se consigue definiendo la etiqueta app: nginx. Esta etiqueta indica al planificador de Kubernetes que no planifique un pod en un nodo trabajador si ya se ejecuta un pod con la misma etiqueta en este nodo trabajador. La etiqueta topologykey: failure-domain.beta.kubernetes.io/zone restringe aún más esta regla antiafinidad y evita que el pod se planifique en un nodo trabajador que se encuentre en la misma zona que un nodo trabajador que ya ejecuta un pod con la etiqueta app: nginx. Para cada pod de conjunto con estado, se crean dos PVC definidas en la sección volumeClaimTemplates, pero la creación de las instancias de File Storage for Classic se retrasa hasta que se planifica un pod de conjunto con estado que utiliza el almacenamiento. Esta configuración se denomina programación de volúmenes en función de la topología.

   apiVersion: storage.k8s.io/v1
   kind: StorageClass
   metadata:
     name: ibmc-file-bronze-delayed
   parameters:
     billingType: hourly
     classVersion: "2"
     iopsPerGB: "2"
     sizeRange: '[20-12000]Gi'
     type: Endurance
   provisioner: ibm.io/ibmc-file
   reclaimPolicy: Delete
   volumeBindingMode: WaitForFirstConsumer
   ---
   apiVersion: v1
   kind: Service
   metadata:
     name: nginx
     labels:
       app: nginx
   spec:
     ports:
     - port: 80
       name: web
     clusterIP: None
     selector:
       app: nginx
   ---
   apiVersion: apps/v1
   kind: StatefulSet
   metadata:
     name: web
   spec:
     serviceName: "nginx"
     replicas: 3
     podManagementPolicy: "Parallel"
     selector:
       matchLabels:
         app: nginx
     template:
       metadata:
         labels:
           app: nginx
       spec:
         affinity:
           podAntiAffinity:
             preferredDuringSchedulingIgnoredDuringExecution:
             - weight: 100
               podAffinityTerm:
                 labelSelector:
                   matchExpressions:
                   - key: app
                     operator: In
                     values:
                     - nginx
                 topologyKey: failure-domain.beta.kubernetes.io/zone
         containers:
         - name: nginx
           image: k8s.gcr.io/nginx-slim:0.8
           ports:
           - containerPort: 80
             name: web
           volumeMounts:
           - name: myvol1
             mountPath: /usr/share/nginx/html
           - name: myvol2
             mountPath: /tmp1
     volumeClaimTemplates:
     - metadata:
         name: myvol1
       spec:
         accessModes:
         - ReadWriteMany # access mode
         resources:
           requests:
             storage: 20Gi
         storageClassName: ibmc-file-bronze-delayed
     - metadata:
         name: myvol2
       spec:
         accessModes:
         - ReadWriteMany # access mode
         resources:
           requests:
             storage: 20Gi
         storageClassName: ibmc-file-bronze-delayed
   

   name

   En los metadatos, especifique un nombre para el conjunto con estado. El nombre que especifique se utilizará para crear el nombre de la PVC con el formato: <volume_name>-<statefulset_name>-<replica_number>.

   serviceName

   En la sección de especificación, especifique el nombre del servicio que desea utilizar para exponer el conjunto con estado.

   replicas

   Especifique el número de réplicas para el conjunto con estado.

   podManagementPolicy

   Especifique la política de gestión de pod que desea utilizar para su conjunto con estado. Puede elegir entre las siguientes opciones.

   • OrderedReady: con esta opción, las réplicas del conjunto con estado se despliegan una después de otra. Por ejemplo, si ha especificado 3 réplicas, Kubernetes crea la PVC para la primera réplica, espera hasta que la PVC esté enlazada, despliegue la réplica del conjunto con estado y monta la PVC en la réplica. Una vez que haya finalizado el despliegue, se despliega la segunda réplica. Para obtener más información sobre esta opción, consulte Gestión de podsOrderedReady.
   • Parallel: con esta opción, todos los despliegues de las réplicas de conjunto con estado se inician al mismo tiempo. Si la app da soporte al despliegue de réplicas en paralelo, utilice esta opción para ahorrar tiempo de despliegue para las PVC y las réplicas de conjuntos con estado.

   matchLabels

   En la sección de selector de especificación, especifique todas las etiquetas que desee incluir en el conjunto con estado y en la PVC. Kubernetes no reconoce las etiquetas que se incluyen en volumeClaimTemplates del conjunto con estado. Revise los siguientes ejemplos de etiqueta.

   • region y zone: si desea que todas las réplicas y PVC del conjunto con estado se creen en una zona específica, añada ambas etiquetas. También puede especificar la zona y la región en la clase de almacenamiento que utiliza. Si no especifica una zona y región y tiene un clúster multizona, la zona en la que se suministra el almacenamiento se selecciona mediante iteración cíclica para equilibrar las solicitudes de volumen de forma uniforme en todas las zonas.
   • billingType: escriba el tipo de facturación que desea utilizar para los PVC. Elija entre hourly o monthly. Si no especifica esta etiqueta, todas las PVC se crean con un tipo de facturación por hora.

   labels

   En la sección de metadatos de la plantilla de especificación, especifique las mismas etiquetas que ha añadido a la sección spec.selector.matchLabels.

   affinity

   En la sección de afinidad de especificación de plantilla de especificación, escriba la regla de antiafinidad para asegurarse de que los pods de conjunto con estado se distribuyen entre nodos trabajadores y zonas. El ejemplo muestra una regla de antiafinidad en la que el pod del conjunto con estado prefiere no estar planificado en un nodo trabajador en el que se ejecuta un pod que tiene la etiqueta app: nginx. La clave topologykey: failure-domain.beta.kubernetes.io/zone restringe aún más esta regla antiafinidad e impide que el pod se planifique en un nodo trabajador si este está en la misma zona que un pod con la etiqueta app: nginx. Mediante esta regla antiafinidad, puede lograr la afinidad entre los nodos trabajadores y las zonas.

   name

   En la sección de metadatos de plantillas de reclamación de volúmenes de especificación, especifique un nombre para el volumen. Utilice el mismo nombre que ha definido en la sección spec.containers.volumeMount.name. El nombre que especifique aquí se utilizará para crear el nombre de la PVC con el siguiente formato: <volume_name>-<statefulset_name>-<replica_number>.

   storage

   En la sección de solicitudes de recursos de especificación de plantillas de reclamación de volúmenes de especificación, escriba el tamaño de File Storage for Classic en gigabytes (Gi).

   iops

   En la sección de solicitudes de recursos de especificación de plantillas de reclamación de volúmenes de especificación, si desea suministrar almacenamiento de rendimiento, especifique el número de IOPS. Si utiliza una clase de almacenamiento de resistencia y especifica un número de IOPS, se pasa por alto el número de IOPS. En su lugar se utiliza el número de IOPS especificado en la clase de almacenamiento.

   storageClassName

   En la sección de especificación de plantillas de reclamación de volúmenes de especificación, escriba la clase de almacenamiento que desea utilizar. Para listar las clases de almacenamiento existentes, ejecute ' oc get sc | grep file. Si no especifica una clase de almacenamiento, la PVC se crea con la clase de almacenamiento predeterminada establecida en el clúster. Asegúrese de que la clase de almacenamiento predeterminada utiliza el suministrador ibm.io/ibmc-file para que el conjunto con estado se suministre con File Storage for Classic.

4. Cree su conjunto con estado.

   oc apply -f statefulset.yaml
   

5. Espere a que se despliegue el conjunto con estado.

   oc describe statefulset <statefulset_name>
   

Para ver el estado actual de los PVC, ejecute oc get pvc. El nombre de su PVC tiene este formato <volume_name>-<statefulset_name>-<replica_number>.

Suministro estático: Utilización de una PVC existente con un conjunto con estado

Puede realizar un suministro previo de las PVC antes de crear el conjunto con estado o utilizar PVC existentes con su conjunto con estado.

Cuando suministre dinámicamente las PVC al crear el conjunto con estado, el nombre de la PVC se asigna en función de los valores que ha utilizado en el archivo YAML de conjunto con estado. Para que el conjunto con estado utilice las PVC existentes, el nombre de las PVC debe coincidir con el nombre que se crearía automáticamente si se utilizara el suministro dinámico.

Antes de empezar: acceda al clúster de Red Hat OpenShift.

1. Si desea suministrar la PVC antes de crear el conjunto con estado, siga los pasos del 1 al 3 de la sección Adición de File Storage for Classic a apps para crear un PVC para cada réplica del conjunto con estado. Cree la PVC con un nombre que respete el siguiente formato: <volume_name>-<statefulset_name>-<replica_number>.

   <volume_name>

   Utilice el nombre que desee especificar en la sección spec.volumeClaimTemplates.metadata.name de su conjunto con estado, como por ejemplo nginxvol.

   <statefulset_name>

   Utilice el nombre que desee especificar en la sección metadata.name de su conjunto con estado, como por ejemplo nginx_statefulset.

   <replica_number>

   Especifique el número de la réplica, empezando por 0.

   Por ejemplo, si tiene que crear 3 réplicas del conjunto con estado, cree 3 PVC con los siguientes nombres: nginxvol-nginx_statefulset-0, nginxvol-nginx_statefulset-1 y nginxvol-nginx_statefulset-2.

   ¿Desea crear una PVC y un PV para una instancia de File Storage for Classic existente? Cree la PVC y el PV mediante suministro estático.

2. Siga los pasos de Suministro dinámico: Creación de la PVC al crear un conjunto con estado para crear el conjunto con estado. El nombre de la PVC sigue el formato <volume_name>-<statefulset_name>-<replica_number>. Asegúrese de usar los valores siguientes a partir del nombre de la PVC en la especificación del conjunto con estado.

   spec.volumeClaimTemplates.metadata.name

   Escriba el <volume_name> del nombre de la PVC.

   metadata.name

   Escriba el <statefulset_name> del nombre de la PVC.

   spec.replicas

   Especifique el número de réplicas que desea crear para el conjunto con estado. El número de réplicas debe ser igual al número de PVC que ha creado anteriormente.

   Si las PVC están en zonas diferentes, no incluya ninguna etiqueta de región o zona en el conjunto con estado.

3. Compruebe que las PVC se usan en los pods de réplica del conjunto con estado listando los pods del clúster e identificando los pods que pertenecen al conjunto con estado.

   oc get pods
   

4. Verifique que la PVC existente esté montada en la réplica del conjunto con estado. Revise el valor de ClaimName en la sección Volumes de la salida de la CLI.

   oc describe pod <pod_name>
   

   Salida de ejemplo

   Name:           nginx-0
   Namespace:      default
   Node:           10.xxx.xx.xxx/10.xxx.xx.xxx
   Start Time:     Fri, 05 Oct 2022 13:24:59 -0400
   ...
   Volumes:
   myvol:
       Type:       PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
       ClaimName:  myvol-nginx-0
   ...
   

Creación de una clase de almacenamiento personalizada con una versión NFS específica

1. Cree una clase de almacenamiento personalizada con la versión de NFS que desea suministrar.

2. Cree una clase de almacenamiento en el clúster.

   oc apply -f nfsversion_storageclass.yaml
   

3. Verifique que se haya creado la clase de almacenamiento personalizada.

   oc get sc
   

4. Suministre File Storage for Classic con la clase de almacenamiento personalizada.

Cambiar su PV existente para utilizar una versión NFS diferente

1. Obtenga el PV del File Storage for Classic cuya versión de NFS desee cambiar y anote el nombre del PV.

   oc get pv
   

2. Añada una anotación a su PV. Sustituya <version_number> por la versión de NFS que desee utilizar. Por ejemplo, para cambiar a NFS versión 3.0, especifique 3.

   oc patch pv <pv_name> -p '{"metadata": {"annotations":{"volume.beta.kubernetes.io/mount-options":"vers=<version_number>"}}}'
   

3. Suprima el pod que utiliza el File Storage for Classic y vuelva a crear el pod.

   1. Guarde el archivo YAML del pod en su máquina local.

      kubect get pod <pod_name> -o yaml > <filepath/pod.yaml>
      

   2. Suprima el pod.

      oc deleted pod <pod_name>
      

   3. Vuelva a crear el pod.

      oc apply -f pod.yaml
      

4. Espere a que se haya desplegado el pod. El pod quedará completamente desplegado cuando el estado cambie a Running.

   oc get pods
   

5. Inicie una sesión en el pod.

   oc exec -it <pod_name> sh
   

6. Verifique que el File Storage for Classic se ha montado con la versión de NFS que ha especificado anteriormente.

   mount | grep "nfs" | awk -F" |," '{ print $5, $8 }'
   

   Salida de ejemplo

   nfs vers=3.0
   

Configuración de instantáneas periódicas

Puede configurar instantáneas periódicas para File Storage for Classic, que constituyen imágenes de solo lectura que captan el estado de la instancia en un punto en el tiempo. Para almacenar la instantánea, debe solicitar espacio de instantáneas en el File Storage for Classic. Las instantáneas se almacenan en la instancia de almacenamiento existente dentro de la misma zona. Puede restaurar datos desde una instantánea si un usuario elimina accidentalmente datos importantes del volumen.

Siga estos pasos para crear una instantánea del volumen.

1. Acceda al clúster de Red Hat OpenShift.

2. Inicie una sesión en la CLI de ibmcloud sl.

   ibmcloud sl init
   

3. Liste los PV en su clúster.

   oc get pv
   

4. Obtenga los detalles de los PV para los que desea crear espacio de instantáneas y anote el ID de volumen, el tamaño y las IOPS. Encontrará el ID de volumen, el tamaño y las IOPS en la sección Labels de la salida de la CLI.

   oc describe pv <pv_name>
   

5. Cree el tamaño de instantánea para el volumen existente con los parámetros que ha recuperado en el paso anterior.

   ibmcloud sl file snapshot-order <volume_ID> --size <size> --tier <iops>
   

6. Espere a que se haya creado el tamaño de la instantánea. El tamaño de instantánea se suministra satisfactoriamente cuando el tamaño de instantánea (GB) cambia en la salida de CLI de 0 al tamaño que ha solicitado.

   ibmcloud sl file volume-detail <volume_ID>
   

7. Cree la instantánea para el volumen y anote el ID de la instantánea que se crea para usted.

   ibmcloud sl file snapshot-create <volume_ID>
   

8. Verifique que la instantánea se haya creado correctamente.

   ibmcloud sl file snapshot-list <volume_ID>
   

9. Establezca la planificación de instantánea. Para obtener más información sobre las opciones disponibles para la planificación de instantáneas, consulte la documentación de CLI.

   ibmcloud sl block snapshot-enable VOLUME_ID <OPTIONS>
   

10. Para restaurar los datos de una instantánea en un volumen existente, ejecute el comando siguiente.

    ibmcloud sl file snapshot-restore <volume_ID> <snapshot_ID>
    

Replicación de instantáneas en otra zona

Para proteger los datos ante un error de la zona, puede replicar instantáneas en una instancia de File Storage for Classic configurada en otra zona.

Los datos únicamente se pueden replicar desde el almacenamiento primario al almacenamiento de copia de seguridad. No puede montar una instancia replicada de File Storage for Classic en un clúster. Cuando el almacenamiento primario falla, puede establecer de forma manual el almacenamiento de copia de seguridad replicado para que sea el primario. A continuación, puede montarla en el clúster. Una vez restaurado el almacenamiento primario, puede restaurar los datos del almacenamiento de copia de seguridad.

Duplicación del almacenamiento

Puede duplicar la instancia de File Storage for Classic en la misma zona que la instancia de almacenamiento original.

La instancia duplicada tiene los mismos datos que la instancia de almacenamiento original en el momento de duplicarla. A diferencia de las réplicas, utilice los duplicados como una instancia de almacenamiento independiente de la original. Para duplicar, primero configure instantáneas para el volumen.

Copia de seguridad de los datos en IBM Cloud® Object Storage

Puede utilizar el diagrama de Helm de ibm-backup-restore acelerar un pod de copia de seguridad y restauración del clúster.

Este pod contiene un script para ejecutar una copia de seguridad puntual o periódico para cualquier reclamación de volumen persistente (PVC) en el clúster. Los datos se almacenan en la instancia de IBM Cloud® Object Storage que ha configurado en una zona.

Para aumentar la alta disponibilidad de los datos y proteger la app ante un error de la zona, configure una segunda instancia de IBM Cloud® Object Storage y replique los datos entre las zonas. Si necesita restaurar datos desde la instancia de IBM Cloud® Object Storage, utilice el script de restauración que se proporciona con el diagrama de Helm.

Copia de datos desde y hacia pods y contenedores

Puede utilizar el comando ' oc cp ' para copiar archivos y directorios a y desde pods o contenedores específicos en su cluster.

Antes de empezar: acceda al clúster de Red Hat OpenShift. Si no especifica ningún contenedor con -c, el mandato utiliza el primer contenedor disponible en el pod.

Copie los datos de la máquina local en un pod del clúster.

oc cp <local_filepath>/<filename> <namespace>/<pod>:<pod_filepath>

Copie los datos de un pod del clúster en la máquina local.

oc cp <namespace>/<pod>:<pod_filepath>/<filename></var> <local_filepath>/<filename>

Copie los datos de la máquina local en un contenedor concreto que ejecute en un pod del clúster.

oc cp <local_filepath>/<filename> <namespace>/<pod>:<pod_filepath> -c CONTAINER

Creación de almacenamiento que tenga en cuenta la topología

Para utilizar el File Storage for Classic en un clúster multizona, su pod debe estar planificado en la misma zona que la instancia de File Storage for Classic para que pueda leer y escribir en el volumen. Antes de que Kubernetes incorporara la planificación del volumen que tiene en cuenta la topología, el suministro dinámico del almacenamiento creaba automáticamente la instancia de File Storage for Classic al crear una PVC. A continuación, cuando creaba el pod, el planificador de Kubernetes intentaba desplegar el pod en un nodo trabajador del mismo centro de datos que la instancia de File Storage for Classic.

La creación de la instancia de File Storage for Classic sin conocer las restricciones del pod puede llevar a resultados no deseados. Por ejemplo, es posible que el pod no pueda planificarse en el mismo nodo trabajador que el almacenamiento porque el nodo trabajador no tiene recursos suficientes o porque el nodo trabajador está marcado y no permite que se planifique el pod. Con la planificación de volumen que tiene en cuenta la topología, la instancia de File Storage for Classic se retrasa hasta que se crea el primer pod que utiliza el almacenamiento.

En los siguientes ejemplos se muestra cómo crear clases de almacenamiento que retrasan la creación de la instancia de File Storage for Classic hasta que el primer pod que utiliza este almacenamiento esté listo para ser planificado. Para retrasar la creación, debe incluir la opción volumeBindingMode: WaitForFirstConsumer. Si no incluye esta opción, el volumeBindingMode se establece automáticamente en Immediate y la instancia de File Storage for Classic se crea al crear la PVC.

Ejemplo de File Storage for Classic de resistencia.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
    name: ibmc-file-bronze-delayed
parameters:
  billingType: hourly
  classVersion: "2"
  iopsPerGB: "2"
  sizeRange: '[20-12000]Gi'
  type: Endurance
  provisioner: ibm.io/ibmc-file
  reclaimPolicy: Delete
  volumeBindingMode: WaitForFirstConsumer

Ejemplo de File Storage for Classic de rendimiento.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
 name: ibmc-file-performance-storageclass
 labels:
   kubernetes.io/cluster-service: "true"
provisioner: ibm.io/ibmc-file
parameters:
 billingType: "hourly"
 classVersion: "2"
 sizeIOPSRange: |-
   "[20-39]Gi:[100-1000]"
   "[40-79]Gi:[100-2000]"
   "[80-99]Gi:[100-4000]"
   "[100-499]Gi:[100-6000]"
   "[500-999]Gi:[100-10000]"
   "[1000-1999]Gi:[100-20000]"
   "[2000-2999]Gi:[200-40000]"
   "[3000-3999]Gi:[200-48000]"
   "[4000-7999]Gi:[300-48000]"
   "[8000-9999]Gi:[500-48000]"
   "[10000-12000]Gi:[1000-48000]"
 type: "Performance"
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer

Especificación de la zona para clústeres multizona

Si desea crear el File Storage for Classic en una zona específica, puede especificar la zona y la región en una clase de almacenamiento personalizada.

Utilice la clase de almacenamiento personalizada si desea suministrar File Storage for Classic de forma estática en una zona específica. En todos los demás casos, especifique la zona directamente en la PVC.

Cuando cree la clase de almacenamiento personalizada, especifique la misma región y la misma zona en la que se encuentran los nodos de clúster y trabajador. Para obtener la región del clúster, ejecute ibmcloud oc cluster get --cluster <cluster_name_or_ID> y busque el prefijo de región en el URL maestro, como eu-de en https://c2.eu-de.containers.cloud.ibm.com:11111. Para obtener la zona del nodo de trabajador, ejecute ibmcloud oc worker ls --cluster <cluster_name_or_ID>.

Ejemplo de File Storage for Classic de resistencia.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
    name: ibmc-file-silver-mycustom-storageclass
labels:
  kubernetes.io/cluster-service: "true"
provisioner: ibm.io/ibmc-file
parameters:
  zone: "dal12"
  region: "us-south"
  type: "Endurance"
  iopsPerGB: "4"
  sizeRange: "[20-12000]Gi"
  reclaimPolicy: "Delete"
  classVersion: "2"
reclaimPolicy: Delete
volumeBindingMode: Immediate

Ejemplo de File Storage for Classic de rendimiento.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
 name: ibmc-file-performance-storageclass
 labels:
   kubernetes.io/cluster-service: "true"
provisioner: ibm.io/ibmc-file
parameters:
  zone: "dal12"
  region: "us-south"
  billingType: "hourly"
  classVersion: "2"
  sizeIOPSRange: |-
   "[20-39]Gi:[100-1000]"
   "[40-79]Gi:[100-2000]"
   "[80-99]Gi:[100-4000]"
   "[100-499]Gi:[100-6000]"
   "[500-999]Gi:[100-10000]"
   "[1000-1999]Gi:[100-20000]"
   "[2000-2999]Gi:[200-40000]"
   "[3000-3999]Gi:[200-48000]"
   "[4000-7999]Gi:[300-48000]"
   "[8000-9999]Gi:[500-48000]"
   "[10000-12000]Gi:[1000-48000]"
  type: "Performance"
reclaimPolicy: Delete
volumeBindingMode: Immediate

Cambio de la versión predeterminada de NFS

La siguiente clase de almacenamiento personalizada le permite definir la versión de NFS que desea suministrar. Por ejemplo, para suministrar NFS versión 3.0, sustituya <nfs_version> por 3.0.

Ejemplo de File Storage for Classic de resistencia.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
    name: ibmc-file-mount
labels:
  kubernetes.io/cluster-service: "true"
provisioner: ibm.io/ibmc-file
parameters:
  type: "Endurance"
  iopsPerGB: "2"
  sizeRange: "[1-12000]Gi"
  reclaimPolicy: "Delete"
  classVersion: "2"
  mountOptions: nfsvers=<nfs_version>

Ejemplo de File Storage for Classic de rendimiento.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
    name: ibmc-file-mount
labels:
  kubernetes.io/cluster-service: "true"
provisioner: ibm.io/ibmc-file
parameters:
  type: "Performance"
  classVersion: "2"
  sizeIOPSRange: |-
    "[20-39]Gi:[100-1000]"
    "[40-79]Gi:[100-2000]"
    "[80-99]Gi:[100-4000]"
    "[100-499]Gi:[100-6000]"
    "[500-999]Gi:[100-10000]"
    "[1000-1999]Gi:[100-20000]"
    "[2000-2999]Gi:[200-40000]"
    "[3000-3999]Gi:[200-48000]"
    "[4000-7999]Gi:[300-48000]"
    "[8000-9999]Gi:[500-48000]"
    "[10000-12000]Gi:[1000-48000]"
  mountOptions: nfsvers=<nfs_version>

Visión general de la eliminación del almacenamiento

La eliminación del almacenamiento persistente de la cuenta de IBM Cloud varía en función de cómo haya suministrado el almacenamiento y de los componentes que ya haya eliminado.

¿Se elimina mi almacenamiento persistente cuando borro mi clúster?

Durante la supresión del clúster, tiene la opción de eliminar el almacenamiento persistente. Sin embargo, en función de cómo se haya suministrado el almacenamiento, es posible que la eliminación del almacenamiento no incluya todos los componentes de almacenamiento. Si aprovisionó almacenamiento dinámicamente con una clase de almacenamiento que establece ' reclaimPolicy: Delete, su PVC, PV y la instancia de almacenamiento se eliminan automáticamente al eliminar el clúster. Para el almacenamiento que se aprovisionó estáticamente o el almacenamiento que aprovisionó con una clase de almacenamiento que establece ' reclaimPolicy: Retain, el PVC y el PV se eliminan cuando se elimina el clúster, pero su instancia de almacenamiento y sus datos permanecen. Se le sigue facturando la instancia de almacenamiento. Además, si ha suprimido el clúster que no está en buen estado, es posible que el almacenamiento siga existiendo incluso si ha elegido eliminarlo.

¿Cómo elimino el almacenamiento si quiero conservar mi clúster?

Cuando se ha suministrado el almacenamiento de forma dinámica con una clase de almacenamiento que establece reclaimPolicy: Delete, puede eliminar la PVC para iniciar el proceso de supresión de su almacenamiento persistente. La PVC, el PV y la instancia de almacenamiento se eliminan automáticamente. Para el almacenamiento que se aprovisionó estáticamente o el almacenamiento que aprovisionó con una clase de almacenamiento que establece " reclaimPolicy: Retain, debe eliminar manualmente el PVC, el PV y la instancia de almacenamiento para evitar más cargos.

¿Cómo se detiene la facturación después de borrar mi almacenamiento?

En función de los componentes de almacenamiento que suprima y de cuándo lo haga, es posible que el ciclo de facturación no se detenga inmediatamente. Si suprime la PVC y el PV, pero no la instancia de almacenamiento de la cuenta de IBM Cloud, dicha instancia sigue existiendo y se le sigue facturando por la misma.

Si suprime la PVC, el PV y la instancia de almacenamiento, el ciclo de facturación se detiene en función del valor de billingType que haya elegido al suministrar el almacenamiento y de cómo haya elegido suprimir el almacenamiento.

• Cuando se cancela manualmente la instancia de almacenamiento persistente desde la consola IBM Cloud o la CLI, la facturación se detiene del siguiente modo:

  • Almacenamiento por hora: la facturación se detiene inmediatamente. Una vez que se haya cancelado el almacenamiento, es posible que siga viendo la instancia de almacenamiento en la consola durante 72 horas más.
  • Almacenamiento mensual: puede elegir entre cancelación inmediata o cancelación al cumplirse el año. En ambos casos, se le factura hasta el final del ciclo de facturación actual y la facturación se detiene en el siguiente ciclo de facturación. Una vez que se haya cancelado el almacenamiento, es posible que siga viendo la instancia de almacenamiento en la consola o la CLI durante 72 horas más.
  • Cancelación inmediata: elija esta opción para eliminar el almacenamiento de inmediato. Ni usted ni sus usuarios pueden seguir utilizando el almacenamiento ni recuperar los datos.
  • Fecha de aniversario: elija esta opción para cancelar el almacenamiento en la fecha del próximo aniversario. Las instancias de almacenamiento permanecen activas hasta la fecha del siguiente aniversario y puede seguir utilizándolas hasta dicha fecha, por ejemplo para dar tiempo a su equipo para que realice copias de seguridad de los datos.

• Si ha suministrado el almacenamiento de forma dinámica con una clase de almacenamiento que establece reclaimPolicy: Delete y elige eliminar la PVC, el PV y la instancia de almacenamiento se eliminan inmediatamente. En el caso del almacenamiento que se factura por hora, la facturación se detiene inmediatamente. En el caso del almacenamiento que se factura mensualmente, se le factura el resto del mes. Una vez que se haya eliminado el almacenamiento y se detiene la facturación, es posible que siga viendo la instancia de almacenamiento en la consola o la CLI durante 72 horas más.

¿Qué debo tener en cuenta antes de eliminar el almacenamiento permanente?

Cuando se limpia el almacenamiento persistente, se suprimen todos los datos almacenados en el mismo. Si necesita una copia de los datos, haga una copia de seguridad.

He borrado mi instancia de almacenamiento. ¿Por qué sigo viendo mi instancia?

Después de eliminar el almacenamiento persistente, pueden pasar hasta 72 horas hasta que la eliminación se procese por completo y el almacenamiento desaparezca de la consola o de la CLI de IBM Cloud.

Limpieza del almacenamiento persistente

Elimine la PVC, el PV y la instancia de almacenamiento de la cuenta de IBM Cloud para evitar cargos adicionales de almacenamiento persistente.

Antes de empezar:

• Asegúrese de que ha realizado una copia de seguridad de los datos que desea conservar.
• Acceda al clúster de Red Hat OpenShift.

Para limpiar los datos persistentes:

1. Obtenga una lista de las PVC del clúster y anote el nombre (NAME) de la PVC, su STORAGECLASS y el nombre del PV vinculado a la PVC que se muestra como VOLUME.

   oc get pvc
   

   Salida de ejemplo

   NAME                  STATUS    VOLUME                                     CAPACITY   ACCESSMODES   STORAGECLASS            AGE
   claim1   Bound     pvc-06886b77-102b-11e8-968a-f6612bb731fb   20Gi       RWO           class       78d
   claim2     Bound     pvc-457a2b96-fafc-11e7-8ff9-b6c8f770356c   4Gi        RWX           class 105d
   claim3      Bound     pvc-1efef0ba-0c48-11e8-968a-f6612bb731fb   24Gi       RWX           class        83d
   

2. Revise los valores ReclaimPolicy y billingType para la clase de almacenamiento.

   oc describe storageclass <storageclass_name>
   

   Si la política de reclamación indica Delete, el PV y el almacenamiento físico se eliminan cuando se elimina la PVC. Si la política de reclamación indica Retain, o si ha suministrado el almacenamiento sin una clase de almacenamiento, el PV y el almacenamiento físico no se eliminan cuando se elimina la PVC. Debe eliminar la PVC, el PV y el almacenamiento físico por separado.

   Si el almacenamiento se carga de forma mensual, se le facturará todo el mes, aunque elimine el almacenamiento antes de que finalice el ciclo de facturación.

3. Elimine los pods que montan la PVC. Obtenga una lista de los pods que montan la PVC. Si no se devuelve ningún pod en la salida de la CLI, no tiene ningún pod que utilice la PVC.

   oc get pods --all-namespaces -o=jsonpath='{range .items[*]}{"\n"}{.metadata.name}{":\t"}{range .spec.volumes[*]}{.persistentVolumeClaim.claimName}{" "}{end}{end}' | grep "<pvc_name>"
   

   Salida de ejemplo

   depl-12345-prz7b:    claim1
   

4. Elimine el pod que utiliza la PVC. Si el pod forma parte de un despliegue, elimine el despliegue.

   oc delete pod <pod_name>
   

5. Verifique que el pod se ha eliminado.

   oc get pods
   

6. Elimine la PVC.

   oc delete pvc <pvc_name>
   

7. Revise el estado de su PV. Utilice el nombre del PV que ha recuperado antes como VOLUME. Cuando se elimina la PVC, se libera el PV vinculado a la PVC. En función de cómo haya suministrado el almacenamiento, el PV entra en estado Deleting si el PV se suprime automáticamente o en estado Released si debe suprimir manualmente el PV. Nota: para los PV que se suprimen automáticamente, el estado puede indicar brevemente Released antes de que se suprima. Vuelva a ejecutar el mandato después de unos minutos para ver si se ha eliminado el PV.

   oc get pv <pv_name>
   

8. Si su PV no se ha suprimido, elimine manualmente el PV.

   oc delete pv <pv_name>
   

9. Verifique que el PV se ha eliminado.

   oc get pv
   

10. Obtenga una lista de la instancia de almacenamiento físico a la que apuntaba su PV y anote el id de la instancia de almacenamiento físico.

    ibmcloud sl file volume-list --columns id  --columns notes | grep <pv_name>
    

    Salida de ejemplo para File Storage for Classic.

    id         notes   
    12345678   {"plugin":"ibm-file-plugin-5b55b7b77b-55bb7","region":"us-south","cluster":"aa1a11a1a11b2b2bb22b22222c3c3333","type":"Endurance","ns":"default","pvc":"mypvc","pv":"pvc-d979977d-d79d-77d9-9d7d-d7d97ddd99d7","storageclass":"ibmc-file-gold"}
    

    "plugin":"ibm-file-plugin-5b55b7b77b-55bb7"

    El plugin de almacenamiento que utiliza el clúster.

    "region":"us-south"

    La región en la que se encuentra el clúster.

    "cluster":"aa1a11a1a11b2b2bb22b22222c3c3333"

    El ID de clúster que está asociado con la instancia de almacenamiento.

    "type":"Endurance"

    El tipo de almacenamiento de archivos o en bloque, Endurance o Performance.

    "ns":"default"

    El espacio de nombres en el que se despliega la instancia de almacenamiento.

    "pvc":"mypvc"

    El nombre del PVC que está asociado a la instancia de almacenamiento.

    "pv":"pvc-d979977d-d79d-77d9-9d7d-d7d97ddd99d7"

    El PV que está asociado con la instancia de almacenamiento.

    "storageclass":"ibmc-file-gold"

    El tipo de clase de almacenamiento: bronce, plata, oro o personalizado.

11. Elimine la instancia de almacenamiento físico.

    ibmcloud sl file volume-cancel <classic_file_id>
    

12. Verifique que se ha eliminado la instancia de almacenamiento físico.

    ibmcloud sl file volume-list
    

El proceso de supresión puede tardar hasta 72 horas en completarse.