Las máquinas virtuales de almacenamiento (SVM) proporcionan aislamiento y separación administrativa entre los inquilinos en un sistema ONTAP. Dedicar una SVM a las aplicaciones permite la delegación de privilegios y permite aplicar las mejores prácticas para limitar el consumo de recursos.

Hay varias opciones disponibles para la gestión del SVM:

En cada caso, la interfaz debe estar en DNS y el nombre DNS debe usarse al configurar Trident. Esto ayuda a facilitar algunos escenarios de recuperación ante desastres, por ejemplo, SVM-DR sin usar la retención de identidad de red.

No hay preferencia entre tener un LIF de administración dedicado o compartido para la SVM, pero debes asegurarte de que tus políticas de seguridad de red se alineen con el enfoque que elijas. De todas formas, el LIF de administración debe ser accesible mediante DNS para facilitar la máxima flexibilidad si "SVM-DR" se usa junto con Trident.

Los sistemas de almacenamiento ONTAP tienen un recuento máximo de volúmenes, que varía según la versión del software y la plataforma de hardware. Consulta "NetApp Hardware Universe" para tu plataforma específica y versión de ONTAP para determinar los límites exactos. Cuando se agota el recuento de volúmenes, las operaciones de aprovisionamiento fallan no solo para Trident, sino para todas las solicitudes de almacenamiento.

Los controladores de Trident ontap-nas y ontap-san aprovisionan un FlexVolume por cada volumen persistente (PV) de Kubernetes que se crea. El controlador ontap-nas-economy crea aproximadamente un FlexVolume por cada 200 PV (configurable entre 50 y 300). El controlador ontap-san-economy crea aproximadamente un FlexVolume por cada 100 PV (configurable entre 50 y 200). Para evitar que Trident consuma todos los volúmenes disponibles en el sistema de almacenamiento, deberías establecer un límite en la SVM. Puedes hacer esto desde la línea de comandos:

El valor de max-volumes varía según varios criterios específicos de tu entorno:

El max-volumes valor es la cantidad total de volúmenes aprovisionados en todos los nodos del clúster de ONTAP, y no en un nodo individual de ONTAP. Como resultado, podrías encontrarte con situaciones en las que un nodo del clúster de ONTAP tenga muchos más o menos volúmenes aprovisionados con Trident que otro nodo.

Por ejemplo, un clúster ONTAP de dos nodos tiene la capacidad de alojar un máximo de 2000 FlexVol volúmenes. Tener el recuento máximo de volúmenes establecido en 1250 parece muy razonable. Sin embargo, si solo "agregados" de un nodo se asignan a la SVM, o los agregados asignados de un nodo no pueden aprovisionarse (por ejemplo, debido a la capacidad), entonces el otro nodo se convierte en el destino de todos los volúmenes aprovisionados por Trident. Esto significa que el límite de volúmenes podría alcanzarse para ese nodo antes de que se alcance el valor de max-volumes, lo que impacta tanto a Trident como a otras operaciones de volúmenes que usan ese nodo. Puedes evitar esta situación asegurándote de que los agregados de cada nodo del clúster se asignen a la SVM que usa Trident en cantidades iguales.

NetApp Trident admite la clonación de volúmenes cuando se usan los ontap-nas, ontap-san y solidfire-san controladores de almacenamiento. Cuando se usan los ontap-nas-flexgroup o ontap-nas-economy controladores, la clonación no está soportada. Crear un volumen nuevo a partir de un volumen existente hará que se cree una nueva instantánea.

Para configurar el tamaño máximo para los volúmenes que puede crear Trident, usa el limitVolumeSize parámetro en tu backend.json definición.

Además de controlar el tamaño del volumen en la matriz de almacenamiento, también deberías aprovechar las capacidades de Kubernetes.

Para configurar el tamaño máximo para los FlexVols usados como pools para los controladores ontap-san-economy y ontap-nas-economy, usa el parámetro limitVolumePoolSize en tu definición backend.json.

Puedes especificar los nombres de usuario y las contraseñas del iniciador y del destino CHAP en la definición del backend y hacer que Trident habilite CHAP en la SVM. Usando el useCHAP parámetro en la configuración del backend, Trident autentica las conexiones iSCSI para backends ONTAP con CHAP.

El uso de una política de QoS de ONTAP aplicada a la SVM limita la cantidad de IOPS consumibles por los volúmenes aprovisionados por Trident. Esto ayuda a "prevenir a un acosador"evitar que un contenedor fuera de control afecte las cargas de trabajo fuera de la SVM de Trident.

Puedes crear una política de QoS para la SVM en pocos pasos. Consulta la documentación de tu versión de ONTAP para la información más precisa. El siguiente ejemplo crea una política de QoS que limita el total de IOPS disponibles para la SVM a 5000.

Además, si tu versión de ONTAP lo admite, puedes considerar usar un mínimo de QoS para garantizar una cantidad de ancho de banda para las cargas de trabajo en contenedores. La QoS adaptativa no es compatible con una política a nivel de SVM.

La cantidad de IOPS dedicadas a las cargas de trabajo en contenedores depende de muchos aspectos. Entre otras cosas, se incluyen:

Es importante recordar que una política de QoS asignada a nivel de SVM implica que todos los volúmenes aprovisionados en la SVM compartan el mismo grupo de IOPS. Si una o un pequeño número de aplicaciones contenedorizadas tienen un alto requerimiento de IOPS, podría convertirse en un obstáculo para las demás cargas de trabajo contenedorizadas. Si este es el caso, podrías considerar usar automatización externa para asignar políticas de QoS por volumen.

La calidad de servicio (QoS) garantiza que el rendimiento de las cargas de trabajo críticas no se degrade por cargas de trabajo competidoras. Los grupos de políticas de QoS de ONTAP ofrecen opciones de QoS para volúmenes y permiten a los usuarios definir el límite de rendimiento para una o más cargas de trabajo. Para más información sobre QoS, consulta "Garantizar el rendimiento con QoS". Puedes especificar grupos de políticas de QoS en el backend o en un pool de almacenamiento, y se aplican a cada volumen creado en ese pool o backend.

ONTAP cuenta con dos tipos de grupos de políticas de QoS: tradicionales y adaptativos. Los grupos de políticas tradicionales proporcionan un máximo fijo (o mínimo, en versiones posteriores) de rendimiento en IOPS. La QoS adaptativa ajusta automáticamente el rendimiento al tamaño de la carga de trabajo, manteniendo la proporción de IOPS a TB o GB a medida que cambia el tamaño de la carga de trabajo. Esto proporciona una ventaja significativa cuando gestionas cientos o miles de cargas de trabajo en una implementación grande.

Ten en cuenta lo siguiente al crear grupos de políticas de QoS:

Para obtener más información sobre los grupos de políticas de QoS, consulta "Referencia de comandos de ONTAP".

Limitar el acceso a los volúmenes NFS, LUN iSCSI y LUN FC creados por Trident es un componente fundamental de la seguridad para tu implementación de Kubernetes. Hacer esto evita que los hosts que no forman parte del clúster de Kubernetes accedan a los volúmenes y puedan modificar los datos de forma inesperada.

Es importante comprender que los espacios de nombres son el límite lógico para los recursos en Kubernetes. Se asume que los recursos en el mismo espacio de nombres se pueden compartir, pero, lo importante es que no existe capacidad entre espacios de nombres. Esto significa que, aunque los PV son objetos globales, cuando se vinculan a un PVC solo son accesibles por pods que están en el mismo espacio de nombres. Es fundamental asegurarse de que los espacios de nombres se usen para proporcionar separación cuando corresponde.

La principal preocupación de la mayoría de las organizaciones con respecto a la seguridad de los datos en un contexto de Kubernetes es que un proceso en un contenedor pueda acceder al almacenamiento montado en el host, pero que no está destinado al contenedor. "Espacios de nombres" están diseñados para evitar este tipo de vulnerabilidad. Sin embargo, hay una excepción: los contenedores privilegiados.

Un contenedor privilegiado es aquel que se ejecuta con muchos más permisos a nivel de host de lo normal. Estos no se deniegan por defecto, así que asegúrate de deshabilitar la capacidad usando "políticas de seguridad de pod".

Para volúmenes a los que se desea acceder tanto desde Kubernetes como desde hosts externos, el almacenamiento debe gestionarse de forma tradicional, con el PV introducido por el administrador y no gestionado por Trident. Esto asegura que el volumen de almacenamiento se destruya solo cuando tanto Kubernetes como los hosts externos se hayan desconectado y ya no estén usando el volumen. Además, se puede aplicar una política de exportación personalizada, que permite el acceso desde los nodos del clúster de Kubernetes y los servidores de destino fuera del clúster de Kubernetes.

Para implementaciones con nodos de infraestructura dedicados (por ejemplo, OpenShift) u otros nodos que no pueden programar aplicaciones de usuario, se deben usar políticas de exportación independientes para limitar aún más el acceso a los recursos de almacenamiento. Esto incluye crear una política de exportación para los servicios que se implementan en esos nodos de infraestructura (por ejemplo, los servicios de Métricas y Registro de OpenShift) y para las aplicaciones estándar que se implementan en nodos que no son de infraestructura.

Debes asegurarte de que exista una política de exportación para cada backend que solo permita el acceso a los nodos presentes en el clúster de Kubernetes. Trident puede crear y administrar políticas de exportación automáticamente. Así, Trident limita el acceso a los volúmenes que aprovisiona a los nodos del clúster de Kubernetes y simplifica la adición y eliminación de nodos.

Como alternativa, también puedes crear una política de exportación manualmente y llenarla con una o más reglas de exportación que procesen cada solicitud de acceso de nodo:

Al ejecutar estos comandos puedes restringir qué nodos de Kubernetes tienen acceso a los datos.

La `showmount`función permite que un cliente de NFS consulte la SVM para obtener una lista de las exportaciones de NFS disponibles. Un pod implementado en el clúster de Kubernetes puede ejecutar el `showmount -e`comando contra la SVM y recibir una lista de los montajes disponibles, incluidos aquellos a los que no tiene acceso. Aunque esto por sí solo no es una vulnerabilidad de seguridad, sí proporciona información innecesaria que podría ayudar a un usuario no autorizado a conectarse a una exportación de NFS.

Debes deshabilitar showmount usando el comando de la línea de comandos de ONTAP a nivel SVM:

Cada cuenta de SolidFire representa a un propietario de volumen único y recibe su propio conjunto de credenciales de Challenge-Handshake Authentication Protocol (CHAP). Puedes acceder a los volúmenes asignados a una cuenta usando el nombre de la cuenta y las credenciales CHAP correspondientes o a través de un grupo de acceso a volúmenes. Una cuenta puede tener hasta dos mil volúmenes asignados, pero un volumen solo puede pertenecer a una cuenta.

Usa las políticas de calidad de servicio (QoS) de SolidFire si quieres crear y guardar una configuración de calidad de servicio estandarizada que puedas aplicar a muchos volúmenes.

Puedes configurar los parámetros de QoS por volumen. El rendimiento de cada volumen se puede garantizar configurando tres parámetros configurables que definen la QoS: Min IOPS, Max IOPS y Burst IOPS.

Aquí tienes los posibles valores mínimos, máximos y de ráfaga de IOPS para el tamaño de bloque de 4Kb.

El tamaño de bloque y el ancho de banda influyen directamente en el número de IOPS. A medida que aumenta el tamaño de bloque, el sistema aumenta el ancho de banda hasta el nivel necesario para procesar los tamaños de bloque más grandes. A medida que aumenta el ancho de banda, disminuye el número de IOPS que el sistema puede alcanzar. Consulta "Calidad de servicio de SolidFire" para más información sobre QoS y rendimiento.

Element admite dos métodos de autenticación: CHAP y Grupos de Acceso a Volumen (VAG). CHAP utiliza el protocolo CHAP para autenticar el host en el backend. Los Grupos de Acceso a Volumen controlan el acceso a los volúmenes que aprovisiona. NetApp recomienda usar CHAP para la autenticación, ya que es más sencillo y no tiene límites de escalabilidad.

La autenticación CHAP (verificación de que el iniciador es el usuario previsto del volumen) solo se admite con control de acceso basado en cuentas. Si usas CHAP para la autenticación, hay dos opciones disponibles: CHAP unidireccional y CHAP bidireccional. El CHAP unidireccional autentica el acceso al volumen usando el nombre de la cuenta SolidFire y el secreto del iniciador. La opción CHAP bidireccional ofrece la forma más segura de autenticar el volumen porque el volumen autentica el host mediante el nombre de la cuenta y el secreto del iniciador, y luego el host autentica el volumen mediante el nombre de la cuenta y el secreto del destino.

Sin embargo, si no se puede habilitar CHAP y se requieren VAG, crea el grupo de acceso y añade los iniciadores de host y los volúmenes al grupo de acceso. Cada IQN que añades a un grupo de acceso puede acceder a cada volumen del grupo con o sin autenticación CHAP. Si el iniciador iSCSI está configurado para usar autenticación CHAP, se utiliza el control de acceso basado en cuentas. Si el iniciador iSCSI no está configurado para usar autenticación CHAP, entonces se utiliza el control de acceso del grupo de acceso a volúmenes.