Maîtriser l'Allocation des Ressources dans SAS Viya : Guide Expert des Launcher Contexts

Dans une architecture moderne basée sur Kubernetes comme SAS^© Viya^™, la gestion des ressources (CPU et RAM) n'est plus statique. Elle devient dynamique et granulaire. L'une des clés pour optimiser les coûts d'infrastructure tout en garantissant la performance des traitements critiques est de sortir du modèle "taille unique" (one-size-fits-all).

Cet article détaille la méthodologie pour implémenter une stratégie de contextes différenciés (Small, Medium, Large) en utilisant les Launcher Contexts, une fonctionnalité puissante mais souvent sous-exploitée de SAS^© Viya^™.

1. Fondamentaux Techniques : La Mécanique Kubernetes

Pour configurer correctement SAS^© Viya^™, il est impératif de comprendre comment le moteur sous-jacent (Kubernetes) alloue les ressources aux pods (les conteneurs exécutant vos sessions SAS^© Compute, Connect ou Batch).

Chaque pod est défini par deux métriques distinctes pour le CPU et la Mémoire. Comprendre la distinction entre Request et Limit est crucial pour éviter des instabilités.

Le concept de "Request" (La Garantie)

La Request est la quantité de ressources que Kubernetes réserve au démarrage du pod.

• Rôle : Elle sert au scheduling (planification). Kubernetes cherche un nœud ayant au moins cette capacité disponible.

• Implication : Si vous fixez une request trop haute, vos pods resteront en état "Pending" faute de place, même si le pod n'utilise pas réellement ces ressources.

Le concept de "Limit" (Le Plafond)

La Limit est la barrière infranchissable imposée au pod une fois qu'il tourne.

• Comportement CPU : Si un processus SAS^© tente de consommer plus de CPU que sa limite, il n'est pas tué, mais bridé (CPU Throttling). Les performances s'effondrent, mais le traitement continue.

• Comportement Mémoire (Danger) : Si un processus dépasse sa limite de RAM, le noyau Linux intervient brutalement via le OOM Killer (Out of Memory Killer) et termine le processus. La session SAS^© plante immédiatement.

Note d'architecture : Lorsque SAS^© Workload Orchestrator est activé (ce qui est le cas par défaut), il ajoute une couche de gestion supplémentaire (files d'attente, priorités) au-dessus de ces mécanismes Kubernetes natifs.

2. La Stratégie : Définir des Profils de Service

Plutôt que de laisser tous les utilisateurs avec les limites par défaut (souvent conservatrices, ex: 2 vCPU), l'objectif est de créer des profils adaptés aux usages :

3. Mise en Œuvre Technique (Pas à Pas)

La configuration se déroule en deux temps dans SAS^© Environment Manager. Il faut d'abord lever les barrières globales avant de créer les contextes spécifiques.

Étape A : Déverrouiller les Plafonds Globaux (sas©.launcher.max)

Par sécurité, SAS^© Viya^™ impose des limites maximales globales. Vous ne pouvez pas créer un contexte "Large" (ex: 8 CPU) si la limite globale est fixée à 2 CPU.

1. Accédez à SAS^© Environment Manager > Configuration.

2. Recherchez le service Launcher service.

3. Éditez l'instance de configuration sas©.launcher.max.

Comme illustré dans les captures de configuration, vous devez augmenter la valeur cpu.limit.

• Action : Passez cpu.limit de la valeur par défaut (souvent 2) à une valeur supérieure (ex: 8 ou plus selon vos nœuds physiques).

• Conseil : Ne touchez pas aux cpu.request globaux si vous n'avez pas de problèmes de placement de pods. Gardez-les bas (ex: 100m) pour faciliter le démarrage des pods.

Étape B : Créer le Launcher Context "Large"

Une fois le plafond global relevé, vous pouvez créer le contexte spécifique.

1. Allez dans Contexts > Vue Launcher contexts.

2. Il est recommandé de dupliquer un contexte existant : Clic droit sur "SAS^© Studio launcher context" > Copy.

3. Nommez-le explicitement, par exemple : SAS© Studio launcher context - large.

4. Ouvrez l'onglet Advanced.

C'est ici que vous surchargez les valeurs par défaut.

• CPU Limit : Saisissez 8 (pour 8 vCPU).

• Memory Limit : Vous pouvez laisser vide (pour utiliser le défaut) ou augmenter la valeur (ex: 8Gi).

• Requests : Il est souvent sage de laisser les champs "Request" vides ou bas (ex: 50m pour le CPU, 300M pour la RAM) pour garantir que le pod puisse démarrer facilement sur le cluster, quitte à ce qu'il consomme plus (jusqu'à la limite) ensuite (mécanisme de burst).

Important : Toute valeur laissée vide dans cet écran héritera des valeurs définies dans sas©.launcher.default.

4. L'Expérience Utilisateur Finale

Une fois ces Launcher Contexts créés (ex: Extra Small, Small, Large), ils ne sont pas directement visibles par l'utilisateur final. Vous devez les associer à des Compute Contexts (Contextes de Calcul).

C'est au niveau du Compute Context (par exemple dans SAS^© Studio) que l'utilisateur choisira son environnement :

• L'utilisateur verra dans sa liste de contextes : "SAS^© Studio Compute - Large", "SAS^© Studio Compute - Standard".

• En sélectionnant "Large", sa session sera instanciée par le Launcher Context configuré avec 8 CPU.

Cela responsabilise les utilisateurs : ils peuvent utiliser un contexte "Standard" économe pour coder, et basculer sur un contexte "Large" uniquement pour exécuter le traitement final.