Los controladores backend de ONTAP se diferencian por el protocolo utilizado y la forma en que se aprovisionan los volúmenes en el sistema de almacenamiento. Por lo tanto, considere cuidadosamente qué controlador implementar.

En un nivel superior, si su aplicación tiene componentes que necesitan almacenamiento compartido (varios pods que acceden al mismo PVC), los controladores basados en NAS serían la opción predeterminada, mientras que los controladores iSCSI basados en bloques satisfacen las necesidades de almacenamiento no compartido. Elija el protocolo en función de los requisitos de la aplicación y el nivel de familiaridad de los equipos de almacenamiento e infraestructura. En términos generales, hay poca diferencia entre ellos para la mayoría de las aplicaciones, por lo que a menudo la decisión se basa en si se necesita o no almacenamiento compartido (donde más de un pod necesitará acceso simultáneo).

Los controladores de backend de ONTAP disponibles son:

Elegir entre los tres controladores NAS tiene algunas repercusiones en las funciones que se ponen a disposición de la aplicación.

Tenga en cuenta que, en las tablas siguientes, no todas las capacidades están expuestas a través de Trident. Algunas de estas funcionalidades deben ser aplicadas por el administrador de almacenamiento después del aprovisionamiento si se desea dicha funcionalidad. Las notas a pie de página en superíndice distinguen la funcionalidad de cada característica y controlador.

Trident ofrece 2 controladores SAN para ONTAP, cuyas capacidades se muestran a continuación.

Las características que no son granulares a nivel de PV se aplican a todo el FlexVolume y todos los PV (es decir, qtrees o LUN en FlexVols compartidos) compartirán una programación común.

Como podemos ver en las tablas anteriores, gran parte de la funcionalidad entre los ontap-nas y ontap-nas-economy es lo mismo. Sin embargo, debido a que ontap-nas-economy El controlador limita la capacidad de controlar la programación a nivel de cada PV, lo que puede afectar especialmente a la planificación de la recuperación ante desastres y las copias de seguridad. Para los equipos de desarrollo que deseen aprovechar la funcionalidad de clonación de PVC en el almacenamiento ONTAP , esto solo es posible al usar el ontap-nas , ontap-san o ontap-san-economy conductores.

Cloud Volumes ONTAP proporciona control de datos junto con funciones de almacenamiento de clase empresarial para diversos casos de uso, incluyendo recursos compartidos de archivos y almacenamiento a nivel de bloque que admiten protocolos NAS y SAN (NFS, SMB/CIFS e iSCSI). Los controladores compatibles para Cloud Volume ONTAP son ontap-nas , ontap-nas-economy , ontap-san y ontap-san-economy . Estas son aplicables a Cloud Volume ONTAP para Azure y Cloud Volume ONTAP para GCP.

Amazon FSx for NetApp ONTAP le permite aprovechar las características, el rendimiento y las capacidades administrativas de NetApp con las que ya está familiarizado, al tiempo que se beneficia de la simplicidad, la agilidad, la seguridad y la escalabilidad del almacenamiento de datos en AWS. FSx para ONTAP admite muchas funciones del sistema de archivos ONTAP y API de administración. Los controladores compatibles para Cloud Volume ONTAP son ontap-nas , ontap-nas-economy , ontap-nas-flexgroup , ontap-san y ontap-san-economy .

El solidfire-san El controlador utilizado con las plataformas NetApp HCI/ SolidFire ayuda al administrador a configurar un backend de Element para Trident en función de los límites de QoS. Si desea diseñar su backend para establecer límites de QoS específicos en los volúmenes aprovisionados por Trident, utilice type parámetro en el archivo backend. El administrador también puede restringir el tamaño del volumen que se puede crear en el almacenamiento mediante la limitVolumeSize parámetro. Actualmente, las funciones de almacenamiento de Element, como el cambio de tamaño y la replicación de volúmenes, no son compatibles con la versión anterior. solidfire-san conductor. Estas operaciones deben realizarse manualmente a través de la interfaz web de Element Software.

Trident utiliza el azure-netapp-files conductor para gestionar el"Azure NetApp Files" servicio.

Encontrará más información sobre este controlador y cómo configurarlo en"Configuración de backend de Trident para Azure NetApp Files" .

Trident utiliza el gcp-cvs Controlador para conectarse con el Cloud Volumes Service en Google Cloud.

El gcp-cvs El controlador utiliza grupos virtuales para abstraer el backend y permitir que Trident determine la ubicación del volumen. El administrador define los grupos virtuales en el backend.json archivos. Las clases de almacenamiento utilizan selectores para identificar los grupos virtuales por etiqueta.

Para configurar el backend de Google Cloud en Trident, debe especificar projectNumber , apiRegion , y apiKey en el archivo de backend. Puedes encontrar el número de proyecto en la consola de Google Cloud. La clave API se toma del archivo de clave privada de la cuenta de servicio que creó al configurar el acceso a la API para Cloud Volumes Service en Google Cloud.

Para obtener detalles sobre los tipos y niveles de servicio de Cloud Volumes Service en Google Cloud, consulte:"Obtenga más información sobre la compatibilidad de Trident con CVS para GCP" .

El filtrado se puede utilizar dentro de un objeto de clase de almacenamiento específico para determinar qué grupo o conjunto de grupos de almacenamiento se utilizará con esa clase de almacenamiento específica. Se pueden configurar tres conjuntos de filtros en la clase de almacenamiento: storagePools , additionalStoragePools , y/o excludeStoragePools .

El storagePools Este parámetro ayuda a restringir el almacenamiento al conjunto de pools que coincidan con los atributos especificados. El additionalStoragePools El parámetro se utiliza para ampliar el conjunto de pools que Trident utiliza para el aprovisionamiento, junto con el conjunto de pools seleccionados por los atributos y storagePools parámetros. Puede utilizar cualquiera de los parámetros por separado o ambos juntos para asegurarse de que se selecciona el conjunto adecuado de grupos de almacenamiento.

El excludeStoragePools El parámetro se utiliza para excluir específicamente el conjunto de pools enumerados que coinciden con los atributos.

Si desea diseñar clases de almacenamiento para emular políticas de calidad de servicio, cree una clase de almacenamiento con la siguiente estructura: media atributo como hdd o ssd . Basado en el media Trident seleccionará el backend apropiado que corresponda al atributo mencionado en la clase de almacenamiento. hdd o ssd agrega para que coincida con el atributo de medios y luego dirige el aprovisionamiento de los volúmenes al agregado específico. Por lo tanto, podemos crear una clase de almacenamiento PREMIUM que tendría media atributo establecido como ssd lo cual podría clasificarse como la política QoS PREMIUM. Podemos crear otra clase de almacenamiento STANDARD que tendría el atributo de medios establecido como hdd, que podría clasificarse como la política QoS STANDARD. También podríamos usar el atributo "IOPS" en la clase de almacenamiento para redirigir el aprovisionamiento a un dispositivo Element que se puede definir como una política de QoS.

Las clases de almacenamiento se pueden diseñar para dirigir el aprovisionamiento de volúmenes en un backend específico donde se habilitan funciones como el aprovisionamiento ligero y grueso, instantáneas, clones y cifrado. Para especificar qué almacenamiento utilizar, cree clases de almacenamiento que especifiquen el backend apropiado con la función requerida habilitada.

Los pools virtuales están disponibles para todos los backends de Trident . Puedes definir grupos virtuales para cualquier backend, utilizando cualquier controlador que proporcione Trident .

Los grupos virtuales permiten a un administrador crear un nivel de abstracción sobre los backends a los que se puede hacer referencia a través de clases de almacenamiento, para una mayor flexibilidad y una ubicación eficiente de los volúmenes en los backends. Se pueden definir diferentes backends con la misma clase de servicio. Además, se pueden crear múltiples grupos de almacenamiento en el mismo backend, pero con características diferentes. Cuando una clase de almacenamiento se configura con un selector con etiquetas específicas, Trident elige un backend que coincida con todas las etiquetas del selector para ubicar el volumen. Si las etiquetas del selector de clase de almacenamiento coinciden con varios grupos de almacenamiento, Trident elegirá uno de ellos para aprovisionar el volumen.

Es posible diseñar pools virtuales para emular clases de servicio. Utilizando la implementación de grupo virtual para Cloud Volume Service para Azure NetApp Files, examinemos cómo podemos configurar diferentes clases de servicio. Configure el backend de Azure NetApp Files con varias etiquetas que representen diferentes niveles de rendimiento. Colocar servicelevel ajuste cada aspecto al nivel de rendimiento adecuado y añada los demás aspectos necesarios bajo cada etiqueta. Ahora crea diferentes clases de almacenamiento de Kubernetes que se correspondan con diferentes grupos virtuales. Utilizando el parameters.selector En cada campo, cada StorageClass especifica qué grupos virtuales se pueden usar para alojar un volumen.

Se pueden diseñar múltiples pools virtuales con un conjunto específico de aspectos a partir de un único backend de almacenamiento. Para ello, configure el backend con múltiples etiquetas y establezca los aspectos necesarios bajo cada etiqueta. Ahora crea diferentes clases de almacenamiento de Kubernetes usando parameters.selector campo que se asignaría a diferentes grupos virtuales. Los volúmenes que se aprovisionan en el backend tendrán los aspectos definidos en el grupo virtual elegido.

Algunos parámetros que van más allá de la clase de almacenamiento solicitada pueden afectar el proceso de decisión de aprovisionamiento de Trident al crear un PVC.

Al solicitar almacenamiento a través de un PVC, uno de los campos obligatorios es el modo de acceso. El modo deseado puede afectar al backend seleccionado para alojar la solicitud de almacenamiento.

Trident intentará hacer coincidir el protocolo de almacenamiento utilizado con el método de acceso especificado según la siguiente matriz. Esto es independiente de la plataforma de almacenamiento subyacente.

Una solicitud de PVC ReadWriteMany enviada a una implementación de Trident sin un backend NFS configurado dará como resultado que no se aprovisione ningún volumen. Por este motivo, el solicitante deberá utilizar el modo de acceso adecuado para su aplicación.

Los volúmenes persistentes son, con dos excepciones, objetos inmutables en Kubernetes. Una vez creada, la política de reclamaciones y su tamaño pueden modificarse. Sin embargo, esto no impide que algunos aspectos del volumen se modifiquen fuera de Kubernetes. Esto puede ser conveniente para personalizar el volumen para aplicaciones específicas, para garantizar que la capacidad no se consuma accidentalmente o simplemente para mover el volumen a un controlador de almacenamiento diferente por cualquier motivo.

Los detalles de conexión del PV no se pueden modificar después de su creación.

Trident admite la creación de instantáneas de volumen bajo demanda y la creación de PVC a partir de instantáneas utilizando el marco CSI. Las instantáneas proporcionan un método conveniente para mantener copias puntuales de los datos y tienen un ciclo de vida independiente del PV de origen en Kubernetes. Estas instantáneas se pueden utilizar para clonar PVC.

Trident también admite la creación de PersistentVolumes a partir de instantáneas de volumen. Para lograr esto, simplemente cree un PersistentVolumeClaim y mencione el datasource como la instantánea requerida a partir de la cual se debe crear el volumen. Trident gestionará este PVC creando un volumen con los datos presentes en la instantánea. Con esta función, es posible duplicar datos entre regiones, crear entornos de prueba, reemplazar un volumen de producción dañado o corrupto en su totalidad, o recuperar archivos y directorios específicos y transferirlos a otro volumen conectado.

Los administradores de almacenamiento tienen la capacidad de mover volúmenes entre agregados y controladores en el clúster ONTAP sin interrumpir el funcionamiento del consumidor de almacenamiento. Esta operación no afecta a Trident ni al clúster de Kubernetes, siempre y cuando el agregado de destino sea uno al que tenga acceso la SVM que utiliza Trident . Es importante destacar que, si el agregado se ha añadido recientemente al SVM, será necesario actualizar el backend volviéndolo a añadir a Trident. Esto hará que Trident reinvente la SVM para que se reconozca el nuevo agregado.

Sin embargo, Trident no admite automáticamente el traslado de volúmenes entre backends. Esto incluye transferencias entre SVM en el mismo clúster, entre clústeres o a una plataforma de almacenamiento diferente (incluso si ese sistema de almacenamiento está conectado a Trident).

Si se copia un volumen a otra ubicación, se puede utilizar la función de importación de volúmenes para importar los volúmenes actuales a Trident.

Trident admite el cambio de tamaño de los volúmenes persistentes (PV) NFS, iSCSI y FC. Esto permite a los usuarios cambiar el tamaño de sus volúmenes directamente a través de la capa de Kubernetes. La expansión de volumen es posible para todas las principales plataformas de almacenamiento de NetApp , incluidos los backends de ONTAP, SolidFire/ NetApp HCI y Cloud Volumes Service . Para permitir una posible expansión posterior, establezca allowVolumeExpansion a true en su StorageClass asociada con el volumen. Siempre que sea necesario cambiar el tamaño del volumen persistente, edite el spec.resources.requests.storage anotación en la reclamación de volumen persistente al tamaño de volumen requerido. Trident se encargará automáticamente de redimensionar el volumen en el clúster de almacenamiento.

La importación de volúmenes ofrece la posibilidad de importar un volumen de almacenamiento existente a un entorno Kubernetes. Actualmente, esto cuenta con el apoyo de ontap-nas , ontap-nas-flexgroup , solidfire-san , azure-netapp-files , y gcp-cvs conductores. Esta función resulta útil al migrar una aplicación existente a Kubernetes o durante escenarios de recuperación ante desastres.

Al utilizar ONTAP y solidfire-san Conductores, utilicen el comando tridentctl import volume <backend-name> <volume-name> -f /path/pvc.yaml Importar un volumen existente a Kubernetes para que sea administrado por Trident. El archivo PVC YAML o JSON utilizado en el comando de importación de volumen apunta a una clase de almacenamiento que identifica a Trident como el proveedor. Cuando utilice un backend NetApp HCI/ SolidFire , asegúrese de que los nombres de los volúmenes sean únicos. Si los nombres de los volúmenes están duplicados, clone el volumen con un nombre único para que la función de importación de volúmenes pueda distinguirlos.

Si el azure-netapp-files o gcp-cvs Se utiliza el controlador, utilice el comando tridentctl import volume <backend-name> <volume path> -f /path/pvc.yaml para importar el volumen a Kubernetes para que sea administrado por Trident. Esto garantiza una referencia de volumen única.

Cuando se ejecute el comando anterior, Trident encontrará el volumen en el servidor y leerá su tamaño. Añadirá automáticamente (y sobrescribirá si es necesario) el tamaño de volumen configurado del PVC. Luego, Trident crea el nuevo PV y Kubernetes vincula el PVC al PV.

Si un contenedor se desplegara de forma que requiriera el PVC importado específico, permanecería en estado pendiente hasta que el par PVC/PV se vinculara mediante el proceso de importación de volumen. Una vez unidos los pares PVC/PV, el contenedor debería subir, siempre que no haya otros problemas.

La implementación y la gestión del almacenamiento para el registro se han documentado en"netapp.io" en el"blog" .

Al igual que otros servicios de OpenShift, el servicio de registro se implementa utilizando Ansible con parámetros de configuración proporcionados por el archivo de inventario, también conocido como hosts, que se proporciona al playbook. Se abordarán dos métodos de instalación: la implementación del registro durante la instalación inicial de OpenShift y la implementación del registro después de que se haya instalado OpenShift.

Si elige usar NFS con el servicio de registro, deberá configurar la variable de Ansible. openshift_enable_unsupported_configurations a true para evitar que falle el instalador.

Con las variables de Ansible apropiadas definidas en su archivo hosts/inventory, implemente el servicio utilizando Ansible. Si realiza la implementación durante la instalación de OpenShift, el PV se creará y utilizará automáticamente. Si realiza la implementación utilizando los playbooks de componentes, después de la instalación de OpenShift, Ansible crea los PVC necesarios y, después de que Trident haya aprovisionado el almacenamiento para ellos, implementa el servicio.

Las variables anteriores, así como el proceso de implementación, pueden cambiar con cada versión de OpenShift. Asegúrese de revisar y seguir"Guía de implementación de OpenShift de Red Hat" para su versión, de modo que esté configurada para su entorno.