Features of ossfs 1.0 and later and ossfs performance benchmarking - Container Service for Kubernetes

Les versions ossfs 1,91 et ultérieures introduisent trois améliorations de performance par rapport à la version 1.88.x : optimisations des opérations POSIX, optimisation readdir et lecture directe (direct read). Si votre cluster utilise Container Storage Interface (CSI) 1.30.1 ou une version ultérieure, activez les feature gates correspondantes pour mettre à jour ossfs.

Les fonctionnalités d'ossfs sont disponibles uniquement sur les nœuds Elastic Compute Service (ECS).

Pour effectuer la mise à niveau, consultez la rubrique Passer à ossfs 1,91 ou version ultérieure.

Évolutions entre la version 1.88.x et la version 1,91

Les sections suivantes décrivent les modifications apportées aux fonctionnalités dans ossfs 1,91 et versions ultérieures. Pour consulter l'intégralité des notes de version, reportez-vous au journal des modifications d'ossfs.

Correctifs des opérations POSIX et valeurs par défaut des paramètres

La version ossfs 1,91 inclut plusieurs correctifs et mises à jour des valeurs par défaut :

Les volumes OSS peuvent désormais être montés sur des sous-chemins qui n'existent pas dans les buckets OSS.
Les fichiers de taille nulle ne sont plus uploadés lors de la création d'un objet. L'erreur EntityTooSmall, qui survenait occasionnellement lors de l'upload multipartie, est corrigée. Les opérations d'ajout (append) sont également améliorées.
Les valeurs par défaut des paramètres sont mises à jour en fonction de la version amont d'ossfs et des résultats des tests de performance.

Le tableau suivant présente les valeurs par défaut des paramètres ayant changé entre les versions 1.88.x et 1,91 :

Paramètre	Description	Valeur par défaut dans la version 1.88.x	Valeur par défaut dans la version 1,91+
`stat_cache_expire`	Durée de vie (TTL) du cache de métadonnées. Unité : secondes.	-1 (aucune expiration)	900
`multipart_threshold`	Seuil de taille de fichier pour l'upload multipartie. Unité : Mo.	5 x 1024	25
`max_dirty_data`	Seuil de taille des données modifiées (dirty data) déclenchant un flush forcé vers le disque. Unité : Mo.	-1 (jamais flushé)	5120

Les paramètres suivants conservent les mêmes valeurs par défaut que la version 1.88.x, mais diffèrent de la version open source d'ossfs 1,91 afin de maintenir un niveau de performance équivalent :

Paramètre	Description	Valeur par défaut dans la version open source 1,91+	Valeur par défaut dans la version Alibaba Cloud 1,91+
`multipart_size`	Taille des parties pour l'upload multipartie. Unité : Mo.	10	30
`parallel_count`	Nombre de parties uploadées simultanément.	5	20

Pour modifier l'un de ces paramètres, mettez à jour le champ otherOpts de votre PV.

Optimisation readdir

Lors du montage d'un volume OSS, ossfs appelle HeadObject pour chaque objet présent dans le chemin monté afin de récupérer des métadonnées telles que les permissions, l'heure de modification, les UID et les GID. Sur les chemins contenant de nombreux objets, ces appels HeadObject peuvent ralentir considérablement les opérations de parcours de répertoire telles que ls et find.

La fonctionnalité d'optimisation readdir ignore ces appels HeadObject, ce qui réduit la latence des opérations sur les répertoires. Prenez connaissance des compromis suivants avant de l'activer :

Les commandes chmod et chown n'ont aucun effet.
Les liens symboliques peuvent ne pas se comporter comme prévu. Les liens physiques ne sont pas pris en charge.

Le tableau suivant décrit les paramètres de la fonctionnalité d'optimisation readdir :

Paramètre	Description	Valeur par défaut
`readdir_optimize`	Active la fonctionnalité d'optimisation readdir. Activez-la avec `-o readdir_optimize` (aucune valeur requise).	Désactivé
`symlink_in_meta`	Enregistre les métadonnées des liens symboliques afin qu'ils s'affichent correctement. Activez cette option avec `-o symlink_in_meta` (aucune valeur requise).	Désactivé

Lecture directe (Direct read)

La fonctionnalité de lecture directe est conçue pour les charges de travail de lecture séquentielle sur des fichiers volumineux. Sans la lecture directe, ossfs télécharge les fichiers depuis OSS vers le disque avant de les lire, ce qui limite le débit de lecture aux performances d'E/S du disque. Avec la lecture directe, ossfs précharge les données depuis OSS directement en mémoire et les lit à partir de là, éliminant ainsi le goulot d'étranglement lié aux E/S disque.

Prenez connaissance des limites suivantes avant d'activer la lecture directe :

Utilisez cette fonctionnalité uniquement pour les lectures séquentielles. Les lectures aléatoires entraînent le redémarrage de la fenêtre de préchargement par ossfs, ce qui dégrade le débit.
Les écritures flushent la mémoire vers le disque pour garantir la cohérence des données.
Une fois la lecture directe activée, le paramètre use_cache n'a aucun effet.

Le tableau suivant décrit les paramètres de la fonctionnalité de lecture directe :

Paramètre	Description	Valeur par défaut
`direct_read`	Active la fonctionnalité de lecture directe. Activez-la avec `-o direct_read` (aucune valeur requise).	Désactivé
`direct_read_prefetch_limit`	Mémoire maximale allouée aux données préchargées pour l'ensemble des processus ossfs. Unité : Mo.	1024 (minimum : 128)

Lorsque les données préchargées atteignent la limite définie par direct_read_prefetch_limit, ossfs arrête le préchargement et le débit de lecture revient à la vitesse des E/S réseau. Pour désactiver entièrement le préchargement en mémoire et lire directement depuis OSS, définissez -o direct_read_prefetch_chunks=0.

Choisir une configuration de lecture

Utilisez le tableau suivant pour sélectionner la configuration adaptée à votre charge de travail :

Charge de travail	Configuration recommandée	Raison
Lectures séquentielles sur des fichiers volumineux, accédés une seule fois	Activez `direct_read` (`-o direct_read`)	Précharge les données en mémoire, élimine les E/S disque
Fichiers petits ou moyens lus de manière répétée depuis le même nœud	Activez le cache de pages du noyau (`-o kernel_cache`)	Réutilise le cache de pages du système d'exploitation entre les lectures
Fichiers lus de manière répétée dont le cache doit survivre aux redémarrages de processus	Activez le cache disque (`-o use_cache=/path/to/cache`)	Persistant après les redémarrages ; capacité supérieure au cache de pages
Grand nombre d'objets, les services n'ont pas besoin des métadonnées des objets	Activez `readdir_optimize` (`-o readdir_optimize`)	Supprime les appels HeadObject par objet lors du parcours des répertoires

direct_read et use_cache s'excluent mutuellement. Lorsque direct_read est activé, use_cache n'a aucun effet.

Bonnes pratiques

Scénarios de lecture/écriture

Pour obtenir les meilleures performances, séparez les lectures et les écritures sur des endpoints OSS distincts. Consultez la rubrique Bonnes pratiques pour la séparation des lectures/écritures OSS.

Si cette séparation n'est pas possible, effectuez une mise à niveau vers ossfs 1,91 ou une version ultérieure pour corriger l'erreur EntityTooSmall lors de l'upload multipartie. Pour garantir la cohérence des données, ajoutez -o max_stat_cache_size=0 au champ otherOpts.

Scénarios en lecture seule

Suivez les recommandations ci-dessous pour choisir une stratégie de mise en cache :

Lecture directe (-o direct_read) : utilisez cette option pour les lectures séquentielles uniques sur des fichiers volumineux lorsque les données ne sont pas consultées à nouveau. Elle élimine les E/S disque en préchargeant les données en mémoire.
Cache de pages du noyau (-o kernel_cache) : utilisez cette option pour les fichiers lus de manière répétée depuis le même nœud. Elle réutilise les données mises en cache entre les lectures sans surcoût d'écriture sur disque.
Cache disque (-o use_cache=/path/to/cache) : utilisez cette option pour les fichiers lus de manière répétée lorsque le cache doit persister après les redémarrages de processus ou dépasser la capacité de la mémoire disponible.

Charges de travail intensives en répertoires

Si un grand nombre d'objets existent dans le bucket OSS et que vos services n'ont pas besoin des métadonnées des objets, activez -o readdir_optimize. Si la gestion des versions est activée pour le bucket OSS, ajoutez également -o listobjectsv2.

Benchmarks de performance

Les résultats ci-dessous ont été obtenus à l'aide de Sysbench ou de scripts personnalisés. Ils varient selon l'outil et l'environnement utilisés.

Important

Tous les benchmarks ont été réalisés sur un nœud ecs.g7.xlarge doté d'un disque système PL0.

Débit (optimisation readdir et lecture directe désactivées)

Sysbench teste 128 fichiers de 8 Mio chacun avec des lectures séquentielles, des écritures séquentielles, des lectures aléatoires et des écritures aléatoires. Par rapport à la version 1.88.x :

La version ossfs 1.88.x offre un débit supérieur pour la création de fichiers et les lectures séquentielles.
Les versions ossfs 1,91 et ultérieures offrent un débit supérieur pour les lectures séquentielles, les lectures aléatoires et les écritures aléatoires.

Latence de parcours de répertoire après activation de l'optimisation readdir

Le test exécute les commandes ls et find sur 1 000 fichiers et enregistre la latence par exécution. Par rapport à ossfs 1.88.x et à ossfs 1,91 avec l'optimisation readdir désactivée :

La latence de ls est inférieure de 74,8 % à celle de la version 1.88.x et de 74,3 % à celle de la version 1,91 avec l'optimisation readdir désactivée, soit une amélioration respective de 4,0x et 3,9x.
La latence de find est inférieure de 58,8 % à celle des versions 1.88.x et 1,91 avec l'optimisation readdir désactivée, soit une amélioration de 2,4x dans les deux cas.

Latence de lecture séquentielle de fichiers volumineux après activation de la lecture directe

Le test lit simultanément 10 fichiers de 10 Gio chacun et enregistre la latence, l'utilisation maximale du disque et l'utilisation maximale de la mémoire.

L'utilisation maximale de la mémoire couvre l'ensemble des processus ossfs, y compris les données préchargées et les autres frais généraux liés à la lecture directe.

Par rapport aux versions 1.88.x et 1,91 avec la lecture directe désactivée :

La latence est inférieure de 85,3 % à celle de la version 1.88.x et de 79 % à celle de la version 1,91 avec la lecture directe désactivée.
L'utilisation maximale du disque est de 0 : aucun fichier temporaire n'est écrit sur le disque.
L'utilisation maximale de la mémoire est légèrement plus élevée, ce qui permet d'atteindre l'utilisation disque nulle mentionnée ci-dessus.

Exécuter vos propres benchmarks

Vous pouvez réaliser des benchmarks d'ossfs dans des conteneurs ou directement sur des instances ECS. Les étapes suivantes utilisent un environnement Sysbench conteneurisé.

Prérequis

Avant de commencer, assurez-vous de disposer des éléments suivants :

Un bucket OSS et une revendication de volume persistant (PVC). Pour la configuration, consultez la rubrique Monter un volume OSS provisionné statiquement

Déployer l'environnement de test Sysbench

Créez un fichier nommé sysbench.yaml avec le contenu suivant. Il déploie un conteneur Sysbench avec le PVC monté sur /data.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: sysbench
  labels:
    app: sysbench
spec:
  replicas: 1
  selector:
    matchLabels:
      app: sysbench
  template:
    metadata:
      labels:
        app: sysbench
    spec:
      containers:
      - name: sysbench
        image: registry.cn-beijing.aliyuncs.com/tool-sys/tf-train-demo:sysbench-sleep
        ports:
        - containerPort: 80
        volumeMounts:
          - name: pvc-oss
            mountPath: "/data"
        livenessProbe:
          exec:
            command:
            - sh
            - -c
            - cd /data
          initialDelaySeconds: 30
          periodSeconds: 30
      volumes:
        - name: pvc-oss
          persistentVolumeClaim:
            claimName: pvc-oss

Déployez l'application Sysbench :
```
kubectl apply -f sysbench.yaml
```

Connectez-vous au conteneur Sysbench, puis exécutez les commandes suivantes dans le chemin de montage pour tester le débit en lecture/écriture.

Ajustez les valeurs des paramètres en fonction des spécifications de votre nœud. Pour les tests consécutifs, préparez de nouveaux fichiers de test à chaque fois afin d'éviter toute interférence du cache.

Opération	Commande
Préparer les fichiers de test	`sysbench --num-threads=2 --max-requests=0 --max-time=120 --file-num=128 --file-block-size=16384 --test=fileio --file-total-size=1G --file-test-mode=rndrw prepare`
Tester les E/S d'écriture séquentielle	`sysbench --num-threads=2 --max-requests=0 --max-time=120 --file-num=128 --file-block-size=16384 --test=fileio --file-total-size=1G --file-test-mode=seqwr --file-fsync-freq=0 run`
Tester les E/S de lecture séquentielle	`sysbench --num-threads=2 --max-requests=0 --max-time=120 --file-num=128 --file-block-size=16384 --test=fileio --file-total-size=1G --file-test-mode=seqrd --file-fsync-freq=0 run`
Tester les E/S de lecture/écriture aléatoire	`sysbench --num-threads=2 --max-requests=0 --max-time=120 --file-num=128 --file-block-size=16384 --test=fileio --file-total-size=1G --file-test-mode=rndrw --file-fsync-freq=0 run`
Supprimer les fichiers de test	`sysbench --test=fileio --file-total-size=1G cleanup`

Étapes suivantes

Vous pouvez réaliser des benchmarks sur différentes versions d'ossfs à l'aide de l'outil de benchmarking MySQL fourni par Sysbench.
Testez l'optimisation readdir en exécutant les commandes ls et find dans le chemin de montage.
Testez la lecture directe en ajoutant -o direct_read au champ otherOpts de votre PV et en exécutant des lectures séquentielles simultanées.