Un módulo básico con dos matrices EF80 ofrece la siguiente disposición de destinos de Lustre. Para conocer la ubicación recomendada de los destinos y las rutas NVMe-oF, consulta "Distribución del volumen principal de bloques de construcción" en "Componentes de hardware".

Cada matriz EF80 utiliza veinticuatro unidades NVMe. Las capacidades admitidas son 3,84 TB, 7,68 TB y 15,3 TB con grupos de volúmenes tradicionales (RAID 1 para MGS/MDT y RAID 6 para OST) o DDP, y unidades Capacity Flash (QLC) de 30,7 TB o 61,4 TB solo con DDP. Actualmente no se recomiendan las unidades de 1,92 TB para esta solución. Para conocer la disposición de las ranuras de unidad y la selección de grupos de unidades, consulta "Componentes de hardware".

En la siguiente tabla se indica la capacidad utilizable aproximada de un módulo EF80 (dos matrices, 48 unidades). La capacidad utilizable de la matriz no es la misma que la capacidad utilizable final del sistema de archivos Lustre. La asignación de nodos de información del MDT, los registros en diario, el sobreaprovisionamiento y los porcentajes de volumen de inventario reducen la capacidad disponible para las aplicaciones.

Define los metadatos y los datos por separado y, a continuación, configura los tamaños de los volúmenes en el inventario de Ansible. Las plantillas de implementación formatean los destinos con ldiskfs; MDT utiliza la proporción de nodos de información predeterminada de Lustre, y las plantillas OST establecen -i 4096.

Ajusta los tamaños de volumen MDT y OST en el inventario según la capacidad de la unidad seleccionada. Modifica format_options.mkfsoptions en eseries_lustre_filesystem_mdt o eseries_lustre_filesystem_ost solo cuando un sitio necesite una relación de nodos de información diferente. Para información sobre las relaciones de nodos de información, consulta "Lustre Wiki: Ajuste de Lustre". Para saber cuándo añadir bloques de construcción, consulta Escalado.

Añade módulos cuando la capacidad o la carga de metadatos lo requiera:

Utiliza mdt.*.md_stats en los MDT existentes para comprobar si los metadatos están saturados. Limita cada clúster de Pacemaker/Corosync a cinco bloques de construcción (diez nodos de servidor OSS/MDS). Para implementaciones más grandes, distribuye los bloques de construcción de manera uniforme entre varios clústeres de alta disponibilidad (HA). Consulta "Arquitectura de la solución" para conocer las reglas de escalabilidad.

El siguiente ejemplo muestra un sistema de archivos con un bloque básico y un bloque exclusivo de OST en un clúster HA.

BB2 registra sus objetivos OST contra el MGS en BB1 usando mgsnode=. Los índices OST de BB2 se asignan globalmente (por ejemplo, OST0032 hasta OST0063) para que ningún índice entre en conflicto con BB1.

La validación formal utiliza IOR, mdtest y fio desde clientes Lustre para caracterizar el rendimiento relativo, las IOPS y el comportamiento de los metadatos, y para validar la conmutación por error de HA. Estas pruebas no publican cifras de rendimiento garantizadas. Las pruebas sintéticas miden el comportamiento en el mejor de los casos y pueden no reflejar el rendimiento real de las aplicaciones.

El rendimiento escala aproximadamente con el número de bloques de construcción. Los resultados obtenidos dependen del tipo de unidad y de la configuración del grupo, del número de rutas NVMe-oF, de la estructura LNet y del número de clientes, así como de la proporción entre E/S de datos y E/S de metadatos.

Ponte en contacto con el equipo de tu cuenta de NetApp para obtener recomendaciones sobre el dimensionamiento y el rendimiento específicas para tu carga de trabajo.

Para ver la configuración de las unidades y el número de volúmenes, consulta "Componentes de hardware". Para ver los pasos de implementación, consulta "Implementa la solución". Para ver la guía de inventario a nivel de campo, consulta "Personaliza el inventario de Ansible de Lustre".