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 fichierspatchTransformer
(Declarative Management of Kubernetes Objects Using Kustomize) , contrairement à Viya 3.x, où la configuration était principalement effectuée viasitedefault.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
- SAS Viya CAS server architecture
- Managing a SAS Viya Platform Deployment
- Add a CAS Server to Your Viya Deployment
- A first look at Migration from SAS Viya 3.x to SAS Viya
- Common Customizations
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
etsas-cas-server-default-worker-[0…N]
. - Conteneurs : Chaque pod de serveur CAS contient généralement trois conteneurs :
cas
,sas-backup-agent
etsas-consul-agent
. - Volumes Persistants : Les serveurs CAS utilisent des volumes persistants pour le stockage, notamment
cas-<casInstance>-permstore
,cas-<casInstance>-data
etsas-cas-backup-data[-<casInstance>]
.
Documentations
- SAS Viya Pods: Cloud Analytic Server (CAS)
- SAS Viya Pods Overview
- Persistent Storage for SAS Viya Software
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 fichiercas-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 manifestesite.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 fichiersusermods
etlogconfig.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 fichierpatchTransformer
yaml dans le répertoiresite-config
et sa référenciation dans le fichierkustomization.yaml
. Cette méthode est particulièrement utile pour les configurations telles queCAS_DISK_CACHE
.
Documentations:
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ètreshutdown
défini surfalse
. - Arrêter : Utilisez
kubectl patch
avec le paramètreshutdown
défini surtrue
. - 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
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 lekustomization.yaml
, et appliquez le manifeste. - Suppression d'un Serveur CAS : Supprimez le
casdeployment
à l'aide dekubectl delete casdeployments
et supprimez les références overlays correspondantes du fichierkustomization.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.
