Cada nodo de almacenamiento AFX de NetApp ofrece un rendimiento específico para lecturas y escrituras. A medida que se añaden nodos al clúster, estos aumentan linealmente dicho rendimiento, como se explica en "Escalado lineal del rendimiento de los nodos".

Actualmente, los tipos de nodo son "AFX 1K" y "AFX 2K" y ofrecen un rendimiento en lectura y escritura aproximadamente en las cantidades que se indican a continuación*. A medida que haya hardware más reciente disponible para NetApp AFX, estos límites pueden cambiar.

Estimaciones de rendimiento por nodo

Cada estantería contiene módulos de estantería de alto rendimiento con 16 puertos Ethernet de 100 GB que aprovechan la comunicación RoCEv2 para una interacción de almacenamiento de ancho de banda elevado con los nodos de computación del clúster. Al igual que cualquier recurso físico, estas estanterías tienen máximos que se pueden alcanzar, especialmente porque NetApp AFX puede presentar múltiples nodos apuntando al mismo conjunto de discos. La siguiente tabla muestra el rendimiento máximo estimado de lectura y escritura para una sola estantería con unidades TLC y QLC. Para obtener más información sobre las diferencias entre TLC y QLC, consulta "TLC frente a QLC".

Estimaciones de rendimiento por estantería

La desvinculación de los nodos de almacenamiento de las estanterías en la arquitectura desagregada de ONTAP permite que más nodos dirijan el tráfico a menos estanterías, lo que ayuda a reducir la huella total del centro de datos necesaria para obtener el máximo rendimiento con solo la capacidad que necesitas.

Este concepto de "densidad de rendimiento" permite a los administradores de almacenamiento aprovechar al máximo el hardware que tienen sin tener que sobreaprovisionar nunca su entorno de almacenamiento.

ONTAP unificado – cómo se divide el rendimiento

Por ejemplo, en un clúster ONTAP unificado, cada nodo tiene su propio conjunto de discos dedicados. Como resultado, el rendimiento se dirige únicamente a los discos que pertenecen al nodo. Como solo un nodo puede acceder a un conjunto de discos, el rendimiento estaría limitado a los discos a los que puede acceder directamente.

NetApp AFX – Densidad de rendimiento

NetApp AFX agrupa todos los discos disponibles en un único conjunto de capacidad llamado Storage Availability Zone (SAZ). Como resultado, todos los nodos pueden aprovechar todos los discos disponibles para lecturas y escrituras. Como los discos y los nodos están desacoplados, no necesariamente necesitarás tantos estantes para obtener el mismo (o mejor) rendimiento de transferencia en comparación con la arquitectura unificada de ONTAP. La arquitectura desagregada de NetApp AFX maximiza el potencial de rendimiento de un estante de discos.

Los nodos de Unified ONTAP requieren al menos un conjunto de discos por nodo y pueden tener varias estanterías conectadas a un único nodo. Como resultado, puede haber cuellos de botella de rendimiento en el único nodo que puede no ser capaz de saturar sus propios discos.

NetApp AFX presenta todos los estantes de discos a todos los nodos. Cada estante contiene módulos con 16 x 100GB interfaces compatibles con RoCE para aumentar la cantidad total de rendimiento permitido por estante. Por esto, puedes saturar un solo estante con varios nodos que estarán leyendo y escribiendo en el mismo conjunto de discos.

A partir de ONTAP 9.19.1, la relación de saturación nodo:bandeja es de al menos 4:1, y 8:3 es posible.

La siguiente sección cubre los resultados de las pruebas de rendimiento utilizando un cluster NetApp AFX con los siguientes parámetros de configuración.

La configuración anterior alcanzó casi el máximo de lecturas disponible para el clúster de 4 nodos (~134GB/s) y se situó justo en el máximo de escrituras permitido por nodo (40GB/s).

NetApp AFX – ElBencho rendimiento de lectura, 4 nodos

NetApp AFX – ElBencho rendimiento de escritura, 4 nodos

En las cargas de trabajo de streaming multimedia, una película 4K suele dividirse en decenas de miles de archivos, cada uno de los cuales suele tener un tamaño de entre 50 MB y 250 MB. Cada archivo representa un fotograma, y la aplicación lee un fotograma completo en una única solicitud. Para mantener un flujo fluido e ininterrumpido sin búferes visibles, estas lecturas de fotogramas deben completarse sin caídas.

ONTAP proporciona una opción a nivel de volumen (-aggressive-readahead-mode para optimizar estas cargas de trabajo. A partir de ONTAP 9.19.1, se ha introducido un nuevo modo cross_file_sequential_read para readahead agresivo en AFX para acelerar las cargas de trabajo con patrones de E/S predecibles a través de tipos de archivo similares (por ejemplo, renderización multimedia y streaming).

cross_file_sequential_read predice el siguiente archivo que se va a leer basándose en su nombre y comienza la lectura anticipada de esos archivos antes de que el cliente emita la llamada de lectura. La lógica de predicción asume que todos los archivos de un directorio siguen un patrón de nomenclatura con un sufijo numérico monotónicamente creciente (por ejemplo, archivo1, archivo2, archivo3). Todos los archivos del directorio deben seguir este patrón, utilizando numeración decimal o hexadecimal. Los nombres de archivo pueden tener hasta 255 caracteres. La lógica es independiente de la extensión y genera el siguiente conjunto de nombres de archivo en el directorio actual basándose únicamente en el nombre de archivo actual. Si un nombre de archivo generado previamente utilizando numeración base10 no existe en el directorio, los nombres se vuelven a generar utilizando numeración hexadecimal. Si no existe ninguno de los nombres de archivo generados, no se emite ninguna precarga para ese conjunto. La precarga se reanuda cuando se emite la siguiente lectura del cliente.

Con estas opciones activadas, las pruebas de rendimiento de "frametest" pudieron leer 30,000 fotogramas 4K a 30 fotogramas por segundo con 30 clientes (NFSv3 y SMB3) y 34 clientes (NFSv4.1), sin que se perdiera ni un solo fotograma.

Aunque la lectura secuencial de archivos cruzados está diseñada principalmente para cargas de trabajo multimedia, también pueden beneficiarse otras cargas de trabajo de lectura intensiva con patrones de acceso y nombres de archivos predecibles, como el entrenamiento y la inferencia de IA.

La versión de NFS 3 ha sido el estándar de oro para las aplicaciones NFS durante décadas, desde 1995, cuando se lanzó oficialmente por primera vez. Su combinación de rendimiento y resiliencia ha hecho que sea difícil considerar un cambio a versiones de NFS más recientes, y con razón.

Sin embargo, NFSv3 no está exento de limitaciones. La falta de estado del protocolo, aunque es genial para el rendimiento y para minimizar las interrupciones en la conmutación por error de almacenamiento, no lo es tanto para la coherencia de los datos y la gestión de bloqueos. Un servidor NFS no realiza un seguimiento real de los estados de bloqueo, así que si ocurre una falla, el servidor NFS puede o no liberar los bloqueos, y el cliente de NFS puede que no sepa si un archivo está bloqueado o no.

La seguridad de NFSv3 también deja algo que desear. El protocolo requiere varios puertos abiertos en el firewall para funcionar correctamente y los identificadores numéricos se envían en texto plano por la red. Además, NFS no tiene un soporte robusto para ACL y no incluye auditoría nativa de archivos y carpetas. Como resultado de estas limitaciones, NFSv4 se creó en 2003 mediante "RFC-3530" (obsoleto en 2015 por "RFC-7530").

Aunque NFSv4.x existe desde hace más de 20 años, aún no se ha generalizado su adopción por varias razones.