Los controladores backend de ONTAP se diferencian por el protocolo utilizado y cómo se aprovisionan los volúmenes en el sistema de almacenamiento. Por lo tanto, piensa bien cuál controlador vas a implementar.

A un nivel superior, si tu aplicación tiene componentes que necesitan almacenamiento compartido (varios pods accediendo al mismo PVC), los controladores basados en NAS serían la opción predeterminada, mientras que los controladores iSCSI basados en bloques cubren las necesidades de almacenamiento no compartido. Elige el protocolo según los requisitos de la aplicación y el nivel de comodidad de los equipos de almacenamiento e infraestructura. En general, hay poca diferencia entre ellos para la mayoría de las aplicaciones, así que muchas veces 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 ONTAP disponibles son:

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

Ten en cuenta que, en las tablas a continuación, no todas las capacidades se exponen a través de Trident. Algunas deben ser aplicadas por el administrador de almacenamiento después del aprovisionamiento si se desea esa funcionalidad. Las notas al pie en superíndice distinguen la funcionalidad por 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 de PV se aplican a todo el FlexVolume y todos los PV (es decir, qtrees o LUNs en FlexVols compartidos) compartirán una programación común.

Como podemos ver en las tablas anteriores, gran parte de la funcionalidad entre el ontap-nas y el ontap-nas-economy es la misma. Sin embargo, porque el ontap-nas-economy driver limita la capacidad de controlar la programación con granularidad por PV, esto puede afectar tu planificación de recuperación ante desastres y copias de seguridad en particular. Para los equipos de desarrollo que quieren aprovechar la funcionalidad de clonado de PVC en almacenamiento ONTAP, esto solo es posible cuando usas los ontap-nas, ontap-san o ontap-san-economy drivers.

Cloud Volumes ONTAP proporciona control de datos junto con funciones de almacenamiento para la gran empresa para varios casos de uso, incluyendo recursos compartidos de archivos y almacenamiento a nivel de bloque que sirven 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. Estos son aplicables para Cloud Volume ONTAP para Azure, Cloud Volume ONTAP para GCP.

Amazon FSx for NetApp ONTAP te permite aprovechar las características, el rendimiento y las capacidades administrativas de NetApp que ya conoces, mientras aprovechas la simplicidad, agilidad, seguridad y escalabilidad de almacenar datos en AWS. FSx for ONTAP es compatible con muchas características del sistema de archivos ONTAP y APIs 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 controlador utilizado con las plataformas NetApp HCI/SolidFire ayuda al admin a configurar un backend de Element para Trident según los límites de QoS. Si quieres diseñar tu backend para establecer límites de QoS específicos en los volúmenes aprovisionados por Trident, usa el type parámetro en el archivo del backend. El admin también puede restringir el tamaño del volumen que se puede crear en el almacenamiento usando el limitVolumeSize parámetro. Actualmente, las funciones de almacenamiento de Element como el redimensionamiento y la replicación de volúmenes no están soportadas a través del solidfire-san controlador. Estas operaciones deben hacerse manualmente desde la interfaz web de Element Software.

Trident utiliza el azure-netapp-files driver para gestionar el "Azure NetApp Files" service.

Más información sobre este controlador y cómo configurarlo la puedes encontrar en "Configuración del backend de Trident para Azure NetApp Files".

El filtrado se puede usar dentro de un objeto de clase de almacenamiento específico para determinar qué grupo o conjunto de grupos de almacenamiento se usará 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 parámetro ayuda a restringir el almacenamiento al conjunto de pools que coinciden con cualquier atributo especificado. El additionalStoragePools parámetro se usa para ampliar el conjunto de pools que Trident utiliza para el aprovisionamiento junto con el conjunto de pools seleccionados por los atributos y los parámetros storagePools. Puedes usar cualquiera de los parámetros por separado o ambos juntos para asegurarte de que se seleccione el conjunto adecuado de pools de almacenamiento.

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

Si quieres diseñar Storage Classes para emular políticas de Quality of Service, crea una Storage Class con el media atributo como hdd o ssd. Según el media atributo mencionado en la storage class, Trident seleccionará el backend adecuado que sirve hdd o ssd aggregates para que coincida con el atributo media y luego dirigirá el aprovisionamiento de los volúmenes al agregado específico. Por eso, podemos crear una storage class PREMIUM que tenga el media atributo establecido como ssd, lo que podría clasificarse como la política de QoS PREMIUM. Podemos crear otra storage class STANDARD que tenga el atributo media establecido como hdd, lo que podría clasificarse como la política de QoS STANDARD. También podemos usar el atributo ``IOPS'' en la storage class para redirigir el aprovisionamiento a un Element appliance, que puede definirse 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 aprovisionamiento fino y grueso, instantáneas, clones y cifrado. Para especificar qué almacenamiento usar, crea clases de almacenamiento que especifiquen el backend adecuado con la función requerida habilitada.

Los grupos virtuales están disponibles para todos los backends de Trident. Puedes definir grupos virtuales para cualquier backend usando cualquier controlador que Trident proporciona.

Los pools virtuales permiten a un administrador crear un nivel de abstracción sobre los backends que se puede referenciar mediante Storage Classes, para mayor flexibilidad y una colocación eficiente de volúmenes en los backends. Se pueden definir diferentes backends con la misma clase de servicio. Además, se pueden crear múltiples storage pools en el mismo backend pero con diferentes características. Cuando una Storage Class se configura con un selector con etiquetas específicas, Trident elige un backend que coincida con todas las etiquetas del selector para colocar el volumen. Si las etiquetas del selector de la Storage Class coinciden con varios storage pools, Trident elegirá uno de ellos para aprovisionar el volumen.

Es posible diseñar grupos virtuales para emular clases de servicio. Usando la implementación de grupo virtual de Cloud Volume Service para Azure NetApp Files, veamos cómo podemos configurar diferentes clases de servicio. Configura el backend de Azure NetApp Files con múltiples etiquetas que representen diferentes niveles de rendimiento. Establece el aspecto servicelevel en el nivel de rendimiento adecuado y agrega otros aspectos necesarios bajo cada etiqueta. Ahora crea diferentes clases de almacenamiento de Kubernetes que se asignarán a diferentes grupos virtuales. Usando el campo parameters.selector, cada StorageClass indica qué grupos virtuales se pueden usar para alojar un volumen.

Se pueden diseñar varios pools virtuales con un conjunto específico de aspectos desde un único backend de almacenamiento. Para hacerlo, configura el backend con varias etiquetas y establece los aspectos necesarios bajo cada etiqueta. Ahora crea diferentes clases de almacenamiento de Kubernetes usando el campo parameters.selector que se asignará a distintos pools virtuales. Los volúmenes que se aprovisionen en el backend tendrán los aspectos definidos en el pool virtual elegido.

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

Cuando solicitas almacenamiento a través de un PVC, uno de los campos obligatorios es el modo de acceso. El modo que elijas puede afectar el 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 un PVC de ReadWriteMany enviada a una implementación de Trident sin un backend NFS configurado dará como resultado que no se aprovisione ningún volumen. Por esta razón, el solicitante debe usar el modo de acceso que sea apropiado para su aplicación.

Los volúmenes persistentes son, con dos excepciones, objetos inmutables en Kubernetes. Una vez creados, la política de recuperación y el tamaño se pueden modificar. Sin embargo, esto no impide que algunos aspectos del volumen se modifiquen fuera de Kubernetes. Esto puede ser deseable para personalizar el volumen para aplicaciones específicas, para asegurarte de 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 la creación.

Trident admite la creación de instantáneas de volumen bajo demanda y la creación de PVCs a partir de instantáneas mediante el framework CSI. Las instantáneas proporcionan un método práctico para mantener copias de un momento específico de los datos y tienen un ciclo de vida independiente del PV de origen en Kubernetes. Estas instantáneas se pueden usar para clonar PVCs.

Trident también admite la creación de PersistentVolumes a partir de instantáneas de volúmenes. Para lograr esto, solo tienes que crear un PersistentVolumeClaim y mencionar el datasource como la instantánea requerida desde 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, puedes duplicar datos entre regiones, crear entornos de prueba, reemplazar un volumen de producción dañado o corrupto por completo, o recuperar archivos y directorios específicos y transferirlos a otro volumen adjunto.

Los administradores de almacenamiento tienen la capacidad de mover volúmenes entre agregados y controladores en el clúster ONTAP de forma no disruptiva para el consumidor de almacenamiento. Esta operación no afecta a Trident ni al clúster Kubernetes, siempre y cuando el agregado de destino sea uno al que la SVM que usa Trident tenga acceso. Lo importante es que, si el agregado se ha añadido recientemente a la SVM, será necesario actualizar el backend volviéndolo a agregar a Trident. Esto hará que Trident vuelva a inventariar la SVM para que se reconozca el nuevo agregado.

Sin embargo, mover volúmenes entre backends no es compatible automáticamente por Trident. Esto incluye entre SVMs en el mismo clúster, entre clústeres o en 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 usar la función de importación de volúmenes para importar los volúmenes actuales en Trident.

Trident admite el cambio de tamaño de NFS, iSCSI y FC PVs. 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 del volumen es posible para todas las principales plataformas de almacenamiento NetApp, incluyendo ONTAP y backends SolidFire/NetApp HCI. Para permitir una posible expansión después, establece allowVolumeExpansion en true en tu StorageClass asociado con el volumen. Cuando sea necesario cambiar el tamaño del volumen persistente, edita la anotación spec.resources.requests.storage en la Persistent Volume Claim al tamaño de volumen requerido. Trident se encargará automáticamente de cambiar el tamaño del volumen en el clúster de almacenamiento.

La importación de volúmenes ofrece la posibilidad de importar un volumen de almacenamiento existente en un entorno Kubernetes. Esto es compatible actualmente con los controladores ontap-nas, ontap-nas-flexgroup, solidfire-san y azure-netapp-files. Esta función es útil cuando portas una aplicación existente a Kubernetes o durante escenarios de recuperación ante desastres.

Cuando uses los controladores ONTAP y solidfire-san utiliza el comando tridentctl import volume <backend-name> <volume-name> -f /path/pvc.yaml para importar un volumen existente en Kubernetes para que sea gestionado por Trident. El archivo YAML o JSON de PVC usado en el comando de importación de volumen apunta a una clase de almacenamiento que identifica a Trident como el provisioner. Cuando uses un backend NetApp HCI/SolidFire, asegúrate de que los nombres de los volúmenes sean únicos. Si los nombres de los volúmenes están duplicados, clona el volumen con un nombre único para que la función de importación de volumen pueda distinguir entre ellos.

Si se utiliza el controlador azure-netapp-files, usa el comando tridentctl import volume <backend-name> <volume path> -f /path/pvc.yaml para importar el volumen en Kubernetes y que sea gestionado por Trident. Esto garantiza una referencia de volumen única.

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

Si un contenedor fue desplegado de tal manera que requería el PVC importado específico, permanecería en estado pendiente hasta que el par PVC/PV se vincule mediante el proceso de importación de volumen. Después de que el par PVC/PV se vincule, el contenedor debería iniciarse, siempre que no haya otros problemas.

El despliegue 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 usando Ansible con parámetros de configuración suministrados por el archivo de inventario, o sea, hosts, proporcionado al playbook. Hay dos métodos de instalación que se van a cubrir: implementar el registro durante la instalación inicial de OpenShift e implementar el registro después de que OpenShift ya esté instalado.

Si decides usar NFS con el servicio de registro, tendrás que establecer la variable de Ansible openshift_enable_unsupported_configurations en true para evitar que el instalador falle.

Con las variables Ansible apropiadas definidas en tu archivo hosts/inventory, despliega el servicio usando Ansible. Si estás desplegando en el momento de instalación de OpenShift, entonces el PV se creará y usará automáticamente. Si estás desplegando usando los playbooks de componentes, después de la instalación de OpenShift, entonces Ansible crea cualquier PVC que sea necesario y, después de que Trident haya aprovisionado almacenamiento para ellos, despliega el servicio.

Las variables anteriores y el proceso de despliegue pueden cambiar con cada versión de OpenShift. Asegúrate de revisar y seguir "Guía de puesta en marcha de OpenShift de Red Hat" para tu versión, así estará configurado para tu entorno.