Un élément de base composé de deux baies EF80 offre la configuration cible Lustre suivante. Pour connaître l’emplacement optimal des cibles et les chemins NVMe-oF, consultez "Répartition du volume de l’élément de base principal" dans "Composants matériels".

Chaque baie EF80 utilise vingt-quatre disques NVMe. Les capacités prises en charge sont de 3,84 To, 7,68 To et 15,3 To avec les groupes de volumes traditionnels (RAID 1 pour MGS/MDT et RAID 6 pour OST) ou DDP, et de 30,7 To ou 61,4 To avec les disques Capacity Flash (QLC) en mode DDP uniquement. Les disques de 1,92 To ne sont actuellement pas recommandés pour cette solution. Pour la disposition des emplacements de disques et la sélection des pools, voir "Composants matériels".

Le tableau suivant indique la capacité utilisable approximative d'un élément de base EF80 (deux baies, 48 disques). La capacité utilisable de la baie n'est pas la même que la capacité utilisable finale du système de fichiers Lustre. L'allocation des inodes MDT, les journaux, le surprovisionnement et les pourcentages de volume d'inventaire réduisent la capacité disponible pour les applications.

Dimensionnez séparément les métadonnées et les données, puis définissez les tailles de volume dans l'inventaire Ansible. Les modèles de déploiement formatent les cibles avec ldiskfs ; MDT utilise le ratio d'inodes par défaut de Lustre et les modèles OST définissent -i 4096.

Ajustez la taille des volumes MDT et OST dans l'inventaire pour la capacité de disque sélectionnée. Modifiez format_options.mkfsoptions dans eseries_lustre_filesystem_mdt ou eseries_lustre_filesystem_ost uniquement lorsqu'un site nécessite un ratio d'inodes différent. Pour plus d'informations sur les ratios d'inodes, consultez la "Lustre Wiki : Réglage Lustre". Pour savoir quand ajouter des éléments de base, consultez Mise à l'échelle.

Ajoutez des éléments de base lorsque la capacité ou la charge des métadonnées l'exigent :

Utilisez mdt.*.md_stats sur les MDT existants pour confirmer si les métadonnées sont saturées. Limitez chaque cluster Pacemaker/Corosync à cinq éléments de base (dix nœuds de serveur OSS/MDS). Pour les déploiements plus importants, répartissez les éléments de base de manière égale entre plusieurs clusters HA. Voir "Architecture de la solution" pour les règles de mise à l'échelle.

L'exemple suivant illustre un système de fichiers avec un élément de base et un élément de base OST uniquement dans un cluster HA.

BB2 enregistre ses cibles OST auprès du MGS dans BB1 en utilisant mgsnode=. Les indices OST pour BB2 sont attribués globalement (par exemple, OST0032 à OST0063) afin qu’aucun indice n’entre en conflit avec BB1.

La validation formelle utilise IOR, mdtest et fio des clients Lustre pour caractériser le débit relatif, les IOPS et le comportement des métadonnées, et pour valider le basculement haute disponibilité. Ces tests ne publient pas de chiffres de performance garantis. Les benchmarks synthétiques mesurent un comportement optimal et peuvent ne pas refléter la performance de l'application.

Les performances augmentent approximativement avec le nombre d'éléments de base. Les résultats obtenus dépendent du type de disque et de la configuration du pool, du nombre de chemins NVMe-oF, du tissu LNet et du nombre de clients, ainsi que de la répartition des E/S entre données et métadonnées.

Contactez votre équipe commerciale NetApp pour obtenir des recommandations de dimensionnement et de performance adaptées à votre charge de travail.

Pour connaître la configuration des disques et le nombre de volumes, consultez "Composants matériels". Pour connaître les étapes de déploiement, consultez "Déployez la solution". Pour obtenir des conseils sur l'inventaire au niveau du terrain, consultez "Personnalisez l'inventaire Ansible de Lustre".