PowerScale : mise à l’échelle des performances des partitions pour suivre les charges applicatives principales de 5 000

Le partitionnement des performances (PP) dans PowerScale OneFS fournit un suivi des charges applicatives principales par jeu de données, permettant aux administrateurs d’identifier les charges applicatives les plus actives (en fonction de l’utilisation du processeur, de la bande passante ou du nombre d’opérations de protocole/disque) sur le cluster.

Les clients qui souhaitent suivre jusqu’à 5 000 charges applicatives principales actives par jeu de données peuvent le faire en appliquant les modifications de configuration décrites dans cet article.

Considérations importantes

• Il s’agit d’une configuration facultative. Le comportement par défaut du cluster reste inchangé.
• La configuration s’applique à l’ensemble du cluster et affecte tous les jeux de données configurés.
• Les requêtes de charge applicative à des échelles plus élevées prennent plus de temps à répondre. L’utilisation de la balise --numeric avec les requêtes CLI est fortement recommandée pour éviter les délais d’expiration.

Conditions préalables

• OneFS 9.15 ou version ultérieure
• Accès à la CLI avec des privilèges root
• Cette configuration a été validée sur les clusters All-Flash avec un maximum de 40 nœuds.
• Compréhension de la configuration des jeux de données de votre cluster et du nombre d’initiateurs actifs

Étape 1 : Appliquer les paramètres PAPI

Exécutez la commande suivante à partir de n’importe quel nœud du cluster. Le paramètre ?force=true est requis. Remplacez <VALUE> par le max_stat_size approprié des conseils de dimensionnement ci-dessous.

curl -sk -u root -H 'Content-Type: application/json' -X PUT \ 'https://<node_IP>:8080/platform/25/performance/settings?force=true' \ -d '{"top_n_collection_count": 5000, "max_top_n_collection_count": 5000, "max_stat_size": <VALUE>}'

Définissez les éléments suivants :

• max_top_n_collection_count : limite supérieure de la collecte de la charge applicative principale. Par défaut : 1 024. Valeur recommandée : 5 000
• top_n_collection_count - Active Top workload collection count. Par défaut : 1 024. Valeur recommandée : 5 000
• max_stat_size : taille maximale de l’échantillon de statistiques en octets. La valeur par défaut est 524 288 (512 Ko). La valeur recommandée varie en fonction de la configuration du cluster. Reportez-vous aux conseils de dimensionnement ci-dessous.

Détermination de l’max_stat_size correcte

Le paramètre max_stat_size contrôle la taille maximale d’un échantillon statistique unique. Cette valeur doit être définie en fonction du nombre de nœuds initiateurs actifs et de jeux de données configurés de votre cluster. Si vous la définissez sur une valeur trop élevée, le service de statistiques risque de dépasser les limites de mémoire lors des requêtes de charge applicative.

La valeur recommandée est calculée à l’aide de la formule suivante :

max_stat_size = min(2700000, 68000000 / (active_initiator_nodes × configured_datasets))

Des exemples sont fournis dans le tableau ci-dessous, afin de sélectionner le max_stat_size approprié pour votre déploiement :

• Pour les clusters avec 1 à 6 nœuds initiateurs et 1 à 4 jeux de données, utilisez 2 700 000.
• Pour les clusters avec 7 à 25 nœuds initiateurs et 1 jeu de données, utilisez 2 700 000.
• Pour les clusters avec 7 à 12 nœuds initiateurs et 2 jeux de données, utilisez 2 700 000.
• Pour les clusters avec 7 à 8 nœuds initiateurs et 3 jeux de données, utilisez 2 700 000.
• Pour 7 nœuds initiateurs avec 4 jeux de données, utilisez 2 428 571.
• Pour 20 nœuds initiateurs avec 2 jeux de données, utilisez 1 700 000.
• Pour 20 nœuds initiateurs avec 3 jeux de données, utilisez 1 133 333.
• Pour 20 nœuds initiateurs avec 4 jeux de données, utilisez 850 000.
• Pour 40 nœuds initiateurs avec 1 jeu de données, utilisez 1 700 000.
• Pour 40 nœuds initiateurs avec 2 jeux de données, utilisez 850 000.
• Pour 40 nœuds initiateurs avec 3 jeux de données, utilisez 566 666.
• Pour 40 nœuds initiateurs avec 4 jeux de données, utilisez 425 000.

Remarque : Pour les grands clusters ou jeux de données avec plusieurs metrics, il se peut qu’il ne prenne pas en charge l’intégralité des 5 000 charges applicatives.

Étape 2 : appliquer les sysctls du noyau

Exécutez la commande suivante pour copier le fichier mis à jour sur tous les nœuds du cluster :

isi_sysctl_cluster "efs.acct.options.max_clients=13000"
isi_sysctl_cluster "efs.acct.options.max_db_actors=16384"
isi_sysctl_cluster "efs.acct.options.max_actor_records=10000"

• efs.acct.options.max_clients : définit le nombre maximal de clients suivis par processeur à l’étape de pipeline de chemin à chaud. Par défaut : 1 000. Valeur recommandée : 13 000
• efs.acct.options.max_db_actors : définit le nombre maximal d’acteurs de base de données par nœud à l’étape du pipeline de classement. Par défaut : 8 192. Valeur recommandée : 16 384
• efs.acct.options.max_actor_records : définit le nombre maximal d’enregistrements d’acteur par nœud à l’étape de pipeline front-end. Par défaut : 1 024. Valeur recommandée : 10 000

ÉTAPE 3 : vérifiez la migration.

Après avoir appliqué les paramètres, vérifiez la configuration PAPI :

curl -sk -u root -X GET 'https://<node_IP>:8080/platform/25/performance/settings'

Vérifiez que top_n_collection_count et max_top_n_collection_count affichent tous deux 5000 et max_stat_size correspond à la valeur sélectionnée dans les conseils de dimensionnement ci-dessus.

Vérifiez les valeurs sysctl :

isi_sysctl_cluster "efs.acct.options.max_clients"
isi_sysctl_cluster "efs.acct.options.max_db_actors"
isi_sysctl_cluster "efs.acct.options.max_actor_records"

Étape 4 : interroger les charges applicatives

Lors de l’interrogation des charges applicatives à l’échelle de 5 000 h, utilisez la balise --numeric pour éviter les délais d’expiration causés par la résolution des chemins et la surcharge de recherche :

isi statistics workloads --numeric

Remarques importantes :

Paramètre max_stat_size trop élevé

Si max_stat_size est défini à un niveau supérieur à celui recommandé pour votre configuration de cluster, cela peut entraîner :

• Échec de la requête de charge applicative active.
• Perte temporaire des statistiques collectées.
• Impact sur les services qui dépendent des statistiques, y compris SmartQoS.

Utilisez toujours la valeur du tableau de dimensionnement qui correspond au nombre de nœuds initiateurs et au nombre de jeux de données de votre cluster.

Modifications de configuration du cluster ou du jeu de données

Si vous ajoutez des nœuds au cluster ou créez des jeux de données supplémentaires après avoir activé 5 000 charges applicatives, la mémoire requise pour les requêtes de charge applicative augmente. Après avoir effectué ces modifications :

• Vérifiez à nouveau le tableau des tailles pour confirmer que votre max_stat_size est toujours approprié pour la nouvelle configuration.
• Si la nouvelle configuration nécessite une max_stat_size inférieure, mettez à jour le paramètre à l’aide de la commande PAPI à l’étape 1.