Astra Trident se lanza cada tres meses: Enero, abril, julio y octubre. Este es un mes después de un lanzamiento de Kubernetes.

Astra Trident no suele admitir funciones alfa en Kubernetes. Trident puede ser compatible con las funciones beta en las dos versiones de Trident que se indican a continuación de la versión beta de Kubernetes.

Astra Trident no tiene dependencia de otros productos de software de NetApp y funciona como una aplicación independiente. Sin embargo, debe disponer de un dispositivo de almacenamiento de entorno de administración de NetApp.

Utilice la tridentctl get Comando para obtener más información acerca de la configuración de Astra Trident.

Sí. Trident 20.01 presenta extremos que se pueden utilizar para recopilar información sobre el funcionamiento de Astra Trident, como el número de back-ends gestionados, el número de volúmenes aprovisionados, bytes consumidos, etc. También puede usar Cloud Insights para la supervisión y el análisis.

No No hay cambios en cuanto a la experiencia del usuario y las funcionalidades. El nombre de aprovisionador usado es csi.trident.netapp.io. Se recomienda este método de instalación de Astra Trident si desea utilizar todas las funciones nuevas que proporcionan las versiones actuales y futuras.

Astra Trident ya no necesita una etcd. Utiliza CRD para mantener el estado.

Sí, Astra Trident se puede instalar sin conexión. Consulte "aquí".

Sí. A partir de la versión Trident 18.10 de Astra se admiten la capacidad de instalación remota desde cualquier máquina que tenga kubectl acceso al clúster. Después kubectl el acceso se verifica (por ejemplo, inicie un kubectl get nodes comando desde la máquina remota para verificar), siga las instrucciones de instalación.

Astra Trident se instala como una implementación de Kubernetes (ReplicaSet) con una instancia, por lo que ha incorporado funciones de alta disponibilidad. No debe aumentar el número de réplicas en la implementación. Si se pierde el nodo en el que se ha instalado Astra Trident o no se puede acceder al pod, Kubernetes vuelve a poner en marcha automáticamente el pod en un nodo correcto del clúster. Astra Trident solo es plano de control, por lo que los pods montados actualmente no se ven afectados si se vuelve a poner en marcha Astra Trident.

Astra Trident lee desde el servidor de API de Kubernetes para determinar cuándo las aplicaciones solicitan nuevos RVP, de modo que necesita acceso al sistema kube.

El instalador de Trident crea un archivo Kubernetes ClusterRole que tiene acceso específico a los recursos Persistent Volume, Persistent Claim, StorageClass y Secret del clúster de Kubernetes. Consulte "aquí".

Si es necesario, puede generar y modificar localmente los archivos de manifiesto exactos que Astra Trident utiliza para la instalación. Consulte "aquí".

Aunque no se aconseja, puede utilizar la misma SVM back-end para dos instancias de Astra Trident. Especifique un nombre de volumen único para cada instancia durante la instalación o especifique un valor único StoragePrefix en la setup/backend.json archivo. De este modo, se garantiza que no se utiliza el mismo FlexVol para ambas instancias.

Astra Trident es simplemente un pod de Kubernetes y se puede instalar dondequiera que se ejecute Kubernetes.

Sí, Astra Trident es compatible con AWS, Google Cloud y Azure.

Sí, Astra Trident es compatible con el servicio Azure NetApp Files en Azure, así como con Cloud Volumes Service en AWS y GCP.

Aunque Astra Trident es un código abierto y se proporciona de forma gratuita, NetApp ofrece total compatibilidad con ella, siempre y cuando su entorno de administración de NetApp sea compatible.

Para levantar un caso de soporte, realice una de las siguientes acciones:

Puede crear un paquete de soporte en ejecución tridentctl logs -a. Además de los registros capturados en el paquete, capture el registro kubelet para diagnosticar los problemas de montaje en el lado de Kubernetes. Las instrucciones para obtener el registro de Kubelet varían en función de cómo se instale Kubernetes.

Cree un problema en "Trident Github" Y mencionar RFE en el tema y descripción del tema.

Cree un problema en "Astra Trident Github". Asegúrese de incluir toda la información y registros necesarios relacionados con el problema.

Si tiene alguna pregunta, problema o solicitud, póngase en contacto con nosotros a través de nuestro "Slack" Team o GitHub.

Actualice la contraseña del back-end con tridentctl update backend myBackend -f </path/to_new_backend.json> -n trident. Sustituya myBackend en el ejemplo con su nombre de fondo, y. `/path/to_new_backend.json con la ruta a la correcta backend.json archivo.

Hay dos supuestos posibles por los que Astra Trident no puede encontrar un nodo de Kubernetes. Puede deberse a un problema de red en Kubernetes o a un problema con el DNS. El conjunto de nodos de Trident que se ejecuta en cada nodo de Kubernetes debe poder comunicarse con la controladora Trident para registrar el nodo en Trident. Si se produjeron cambios en la red después de instalar Astra Trident, solo se produce este problema con los nodos de Kubernetes nuevos que se añaden al clúster.

No se perderán los datos si el pod de Trident se destruye. Los metadatos de Trident se almacenan en objetos CRD. Todos los VP aprovisionados por Trident funcionarán normalmente.

NetApp admite la actualización de Astra Trident de una versión principal a la siguiente inmediata mayor. Puede actualizar de la versión 18.xx a la 19.xx, 19.xx a la 20.xx, etc. Debe realizar pruebas de actualización en un laboratorio antes de la implementación de producción.

Hay una serie de factores que se deben evaluar si se desea cambiar a una versión inferior. Consulte "la sección de la degradación".

NetApp recomienda tener ambos en el archivo de definición de back-end. Sin embargo, el LIF de gestión es el único que es obligatorio.

Sí. A partir de 20.04, Astra Trident admite CHAP bidireccional para los back-ends de ONTAP. Esto requiere configuración useCHAP=true en la configuración de back-end.

Astra Trident puede crear y gestionar dinámicamente políticas de exportación a partir de la versión 20.04. Esto permite al administrador de almacenamiento proporcionar uno o varios bloques CIDR en la configuración back-end y hacer que Trident añada IP de nodo dentro de estos rangos a una política de exportación que cree. De esta forma, Astra Trident gestiona automáticamente la adición y eliminación de reglas para nodos con IP en los CIDR dados. Esta función requiere CSI Trident.

Astra Trident 19.01 y versiones posteriores admiten la especificación de un puerto en DataLIF. Configúrelo en la backend.json archivo como “managementLIF”: <ip address>:<port>”. Por ejemplo, si la dirección IP del LIF de gestión es 192.0.2.1 y el puerto es 1000, configure "managementLIF": "192.0.2.1:1000".

Sí. Astra Trident 20.01 admite la definición de direcciones IPv6 para los parámetros managementLIF y dataLIF para los back-ends de ONTAP. Debe asegurarse de que la dirección siga a la semántica de IPv6 y la dirección managementLIF se define entre corchetes (por ejemplo, [ec0d:6504:a9c1:ae67:53d1:4bdf:ab32:e233]). También debe asegurarse de que Astra Trident se instale mediante el `--use-ipv6 Le permite que funcione a través de IPv6.

Sí, es posible actualizar la LIF de gestión del back-end mediante el tridentctl update backend comando.

No, no es posible actualizar la LIF de datos en el back-end.

Astra Trident puede admitir muchos back-ends simultáneamente, ya sea con el mismo controlador o con distintos controladores.

Astra Trident almacena las credenciales de back-end como secretos de Kubernetes.

Si los atributos back-end no se pueden utilizar para seleccionar automáticamente los grupos adecuados para una clase, el storagePools y.. additionalStoragePools los parámetros se usan para seleccionar un conjunto específico de pools.

La excludeStoragePools El parámetro se utiliza para filtrar el conjunto de pools que utilizará Astra Trident para el aprovisionamiento y eliminará cualquier pool que coincida.

Si hay varios back-ends configurados del mismo tipo, Astra Trident selecciona el back-end adecuado en función de los parámetros presentes en StorageClass y.. PersistentVolumeClaim. Por ejemplo, si hay varios back-ends de unidades ontap-nas, Astra Trident intenta coincidir con los parámetros en StorageClass y.. PersistentVolumeClaim combine y haga coincidir un back-end que pueda cumplir los requisitos enumerados en StorageClass y.. PersistentVolumeClaim. Si hay varios back-ends que coincidan con la solicitud, Astra Trident selecciona de uno de ellos al azar.

Sí.

La ontap-nas-economy El controlador crea hasta 200 qtrees en la misma FlexVol (que se puede configurar entre 50 y 300), 100,000 qtrees por nodo del clúster y 2,4 MILLONES por clúster. Al introducir un nuevo PersistentVolumeClaim Este servicio es prestado por el conductor económico y busca ver si ya existe una FlexVol que pueda dar servicio al nuevo qtree. Si no existe la FlexVol que pueda dar servicio al qtree, se crea una nueva FlexVol.

Puede establecer permisos Unix en el volumen aprovisionado por Astra Trident mediante la configuración de un parámetro en el archivo de definición del back-end.

De forma predeterminada, Astra Trident no establece las opciones de montaje en ningún valor con Kubernetes. Para especificar las opciones de montaje en la clase de almacenamiento Kubernetes, siga el ejemplo dado "aquí".

Para permitir el acceso de hosts adecuados a un volumen, use el exportPolicy parámetro configurado en el archivo de definición de backend.

Puede establecer el cifrado en el volumen aprovisionado por Trident mediante el parámetro Encryption del archivo de definición del back-end.

Uso StorageClasses Para implementar QoS en ONTAP.

Los controladores ONTAP admiten thin provisioning o thick. Los controladores ONTAP, de manera predeterminada, son thin provisioning. Si se desea un aprovisionamiento grueso, debe configurar el archivo de definición back-end o el StorageClass. Si se configuran ambas, StorageClass tiene prioridad. Configure lo siguiente para ONTAP:

La protección contra RVP se habilita automáticamente en Kubernetes a partir de la versión 1.10.

Sí. Puede ampliar una RVP creada por Astra Trident. Tenga en cuenta que el crecimiento automático del volumen es una función de ONTAP que no se aplica a Trident.

A partir de la versión 19.04, se puede usar la función de importación de volúmenes para llevar los volúmenes a Kubernetes.

Se produce un error en la importación del volumen si el volumen externo está en modo DP o sin conexión. Recibe el siguiente mensaje de error:

Trident 19.10 admite la ampliación de VP iSCSI mediante el aprovisionador CSI.

La cuota de recursos de almacenamiento de Kubernetes debe funcionar siempre que el almacenamiento de NetApp tenga capacidad. Cuando el almacenamiento de NetApp no puede respetar la configuración de cuota de Kubernetes por falta de capacidad, Astra Trident intenta aprovisionar, pero con errores.

Sí. Astra Trident admite la creación de snapshots de volúmenes bajo demanda y volúmenes persistentes a partir de snapshots. Para crear VP a partir de instantáneas, asegúrese de que VolumeSnapshotDataSource se ha habilitado la puerta de operaciones.

A partir de ahora, ofrecemos soporte de copias Snapshot bajo demanda para nuestro ontap-nas, ontap-nas-flexgroup, ontap-san, ontap-san-economy, solidfire-san, aws-cvs, gcp-cvs, y. azure-netapp-files controladores de back-end.

Este está disponible en ontap-nas, ontap-san, y. ontap-nas-flexgroup de windows También puede especificar un snapshotPolicy para la ontap-san-economy Controlador en el nivel FlexVol.

También está disponible en la ontap-nas-economy Pero con la granularidad del nivel de FlexVol, no con la granularidad del qtree. Para permitir la capacidad de realizar copias Snapshot de volúmenes aprovisionados por Astra Trident, establezca la opción de parámetro backend snapshotPolicy A la política de Snapshot deseada según se define en el back-end de ONTAP. Astra Trident no conoce las instantáneas que tome la controladora de almacenamiento.

Sí, puede reservar un porcentaje específico de espacio en disco para almacenar las copias Snapshot mediante Astra Trident estableciendo el snapshotReserve atributo en el archivo de definición de backend. Si se configuró snapshotPolicy y.. snapshotReserve en el archivo de definición de backend, el porcentaje de reserva de instantánea se establece según la snapshotReserve porcentaje mencionado en el archivo back-end. Si la snapshotReserve No se menciona ningún número de porcentaje. ONTAP toma el porcentaje de reserva de snapshots de forma predeterminada en 5. Si la snapshotPolicy la opción se establece en none, el porcentaje de reserva de snapshot se establece en 0.

Sí, es posible acceder al directorio Snapshot en el volumen aprovisionado por Trident estableciendo el snapshotDir parámetro en el archivo de definición de backend.

Actualmente, SnapMirror debe configurarse externamente mediante la CLI de ONTAP o System Manager de OnCommand.

Para restaurar un volumen a una copia de Snapshot de ONTAP, realice los siguientes pasos:

Se pueden crear reflejos de uso compartido de carga para volúmenes raíz de los SVM que sirven datos mediante NFS. ONTAP actualiza automáticamente los reflejos de uso compartido de carga para los volúmenes creados por Trident. Esto puede provocar retrasos en el montaje de volúmenes. Cuando se crean varios volúmenes mediante Trident, el aprovisionamiento de un volumen depende de que ONTAP actualice el reflejo de uso compartido de carga.

Kubernetes no permite las clases de almacenamiento en espacios de nombres. Sin embargo, puede utilizar Kubernetes para limitar el uso de una clase de almacenamiento específica por espacio de nombres mediante las cuotas de recursos de almacenamiento, que se encuentran por espacio de nombres. Para denegar el acceso a un espacio de nombres específico a un almacenamiento específico, establezca la cuota de recursos en 0 para esa clase de almacenamiento.