Gestion du Serveur CAS dans SAS Viya4

Le serveur SAS Cloud Analytic Services (CAS) est un composant essentiel de la plateforme SAS Viya, responsable de l'exécution du traitement des données et des analyses.

Une gestion efficace du serveur CAS est cruciale pour maintenir un environnement SAS Viya sain et performant.

Cet article fournit une vue d'ensemble de la gestion du serveur CAS dans SAS Viya, couvrant divers aspects tels que la configuration, la gestion de la topologie, le cycle de vie du serveur et la surveillance des sessions.

Aperçu du Serveur CAS

Dans SAS Viya, un serveur CAS est représenté par un casdeployment dans Kubernetes. Chaque casdeployment correspond à une instance de serveur CAS spécifique. Les serveurs CAS dans Viya peuvent être déployés en mode Symmetric Multi-Processing (SMP) ou Massively Parallel Processing (MPP). Les principales différences entre le serveur CAS dans Viya et Viya 3.x comprennent :

Dans Viya, plusieurs pods CAS peuvent s'exécuter sur un seul nœud Kubernetes (sans AUTORESOURCES), et plusieurs serveurs CAS peuvent coexister sur les mêmes nœuds Kubernetes. Avec AUTORESOURCES, chaque pod CAS nécessite son propre nœud Kubernetes, et plusieurs serveurs CAS ne peuvent pas coexister sur les mêmes machines.
La configuration du serveur CAS dans Viya est gérée via SAS Environment Manager, la CLI sas-viya ou les fichiers patchTransformer (Declarative Management of Kubernetes Objects Using Kustomize) , contrairement à Viya 3.x, où la configuration était principalement effectuée via sitedefault.yml et les fichiers de configuration du serveur CAS.
Viya utilise un pod opérateur CAS pour gérer les contrôleurs secondaires/de sauvegarde, en utilisant des volumes persistants partagés entre les pods CAS.

Documentations

Composants du Serveur CAS dans Kubernetes

La compréhension des composants Kubernetes sous-jacents est cruciale pour une gestion efficace du serveur CAS. Les composants clés comprennent :

Opérateur CAS : Le sas-cas-operator-[UUID] gère tous les serveurs CAS dans un espace de noms de déploiement Viya.
Pods CAS : Selon la topologie du serveur CAS (SMP/MPP), il peut y avoir plusieurs pods CAS, tels que sas-cas-server-default-backup, sas-cas-server-default-controller et sas-cas-server-default-worker-[0…N].
Conteneurs : Chaque pod de serveur CAS contient généralement trois conteneurs : cas, sas-backup-agent et sas-consul-agent.
Volumes Persistants : Les serveurs CAS utilisent des volumes persistants pour le stockage, notamment cas-<casInstance>-permstore, cas-<casInstance>-data et sas-cas-backup-data[-<casInstance>].

Documentations

Gestion de la Topologie du Serveur CAS

La topologie du serveur CAS peut être modifiée pour ajuster les capacités de traitement du serveur. Les changements de topologie peuvent impliquer le passage de SMP à MPP, l'ajout/la suppression de nœuds de travail en mode MPP, ou la gestion des contrôleurs secondaires/de sauvegarde.

SMP à MPP : Pour passer un serveur CAS de SMP à MPP, vous devez ajouter au moins un nœud de travail. Cela implique la création et l'application d'un fichier cas-manage-workers.yaml. Notez que ce changement nécessite un redémarrage du serveur CAS, ce qui signifie que les données doivent être rechargées.
Gestion des Workers MPP : Les nœuds de travail peuvent être ajoutés ou supprimés d'un serveur CAS MPP. L'ajout de workers ne nécessite pas de redémarrage du serveur, mais la suppression de workers en nécessite un (selon la position officielle de SAS).
Contrôleur Secondaire/de Sauvegarde : Un contrôleur secondaire/de sauvegarde peut être ajouté à un serveur CAS MPP en définissant la variable backupControllers sur 1 dans le fichier cas-manage-backup.yaml. L'ajout ou la suppression d'un contrôleur secondaire/de sauvegarde nécessite un redémarrage du serveur CAS.

Les overlays du serveur CAS, situés dans sas-bases/overlays/cas-server/, définissent les configurations initiales des serveurs CAS. Ces overlays sont inclus dans le fichier kustomization.yaml.

Documentations

Configuration du Serveur CAS

Les configurations du serveur CAS sont conservées dans Consul et chargées dans /cas/config lors de l'initialisation du serveur CAS. Ces configurations déterminent le comportement du serveur CAS et sont gérées par différentes méthodes :

sitedefault.yaml : Utilisé avant le déploiement pour configurer Viya et le serveur CAS.
Fichiers patchTransformers yaml : Utilisés après le déploiement pour ajuster le serveur CAS. Nécessite la construction et l'application du manifeste site.yaml.
SAS Environment Manager et CLI sas-viya : Utilisés pour ajuster le serveur CAS sur un déploiement Viya déployé et en cours d'exécution. Ces outils sont utilisés pour modifier les fichiers usermods et logconfig.xml.

Documentations

SAS Cloud Analytic Services: Reference
SAS Cloud Analytic Services: How To (CLI)
"SAS Viya CAS server patchTransformer"
"SAS Viya CAS Environment Manager configuration"
"SAS Viya CAS server sas-viya CLI configuration"

Modification de la Configuration du Serveur CAS

Les configurations du serveur CAS peuvent être modifiées à l'aide de SAS Environment Manager, de la CLI sas-viya ou des fichiers patchTransformer yaml.

SAS Environment Manager : Fournit une interface graphique pour modifier les configurations du serveur CAS.
CLI sas-viya : Permet la modification des configurations en ligne de commande. Cela implique de télécharger les configurations sous forme de fichier JSON, de modifier le fichier, puis de mettre à jour la configuration à l'aide du fichier modifié.
Fichier patchTransformer yaml : Implique la création d'un fichier patchTransformer yaml dans le répertoire site-config et sa référenciation dans le fichier kustomization.yaml. Cette méthode est particulièrement utile pour les configurations telles que CAS_DISK_CACHE.

Documentations:

Consider relocating CAS_DISK_CACHE

Gestion du Cycle de Vie du Serveur CAS

Les serveurs CAS peuvent être gérés à l'aide de la CLI kubectl pour les démarrer, les arrêter ou les redémarrer. Cela nécessite des autorisations Kubernetes appropriées pour l'administrateur Viya.

Démarrer : Utilisez kubectl patch avec le paramètre shutdown défini sur false.
Arrêter : Utilisez kubectl patch avec le paramètre shutdown défini sur true.
Redémarrer : Redémarrez tous les serveurs CAS en supprimant les pods gérés par l'opérateur CAS ou redémarrez un serveur CAS spécifique en supprimant les pods associés à cette instance.

Documentations

SAS Viya – CAS Server Life Cycle Management

Ajout et Suppression de Serveurs CAS

SAS fournit un script (create-cas-server.sh) pour simplifier le processus d'ajout de nouveaux serveurs CAS. La suppression d'un serveur CAS implique la suppression du casdeployment et la suppression de ses références du fichier kustomization.yaml.

Ajout d'un Serveur CAS : Utilisez le script create-cas-server.sh pour générer les fichiers overlays nécessaires, référencez ces fichiers dans le kustomization.yaml, et appliquez le manifeste.
Suppression d'un Serveur CAS : Supprimez le casdeployment à l'aide de kubectl delete casdeployments et supprimez les références overlays correspondantes du fichier kustomization.yaml.

Surveillance et Gestion des Sessions CAS

Les sessions du serveur CAS peuvent être surveillées et gérées à l'aide de la CLI kubectl, de la CLI sas-viya ou de SAS Environment Manager. Cependant, il est important de noter que le tableau de bord Grafana SAS CAS Overview ne fournit pas d'informations au niveau de la session.

CLI kubectl : Permet de surveiller les sessions en examinant les processus à l'intérieur du conteneur CAS et de gérer les sessions en terminant des processus de session spécifiques.
CLI sas-viya : Fournit des commandes pour lister, créer, afficher des informations sur et supprimer des sessions de serveur CAS.
SAS Environment Manager : Offre une interface graphique pour afficher et terminer les sessions du serveur CAS.

Meilleures Pratiques et Considérations

Lors de la modification des configurations du serveur CAS, faites preuve de prudence.
Pour plus de cohérence, envisagez de créer tous les nouveaux serveurs CAS en tant que SMP, puis de les modifier en MPP au besoin.
Adoptez une stratégie claire pour la gestion des fichiers patchTransformer yaml du serveur CAS dans les déploiements multi-serveurs.