Aujourd'hui, je vous présente comment déployer un second CAS controller sur une installation SAS Viya 3.5 existante. En effet, depuis SAS Viya 3.4, il est possible d'avoir plusieurs instances de serveurs CAS dans une seule instance de SAS Viya.
En complément de cet article, je vous propose également une vidéo présentant, étape par étape, le déploiement d'un second CAS Controller dans SAS Viya 3.5. Cette vidéo est disponible sur ma chaîne Youtube : https://youtu.be/K6SYrG7UB90
Avant de rentrer dans le vif du sujet, je vous propose un rapide rappel des deux modes d'installation possibles de SAS Viya, le SMP et le MPP. Dans un environnement de SMP, c'est à dire un seul serveur linux, un serveur CAS est constitué d'un contrôleur et fonctionne sur une seule machine :
Dans un environnement de traitement MPP (massively parallel processing), un serveur CAS distribué se compose d'un CAS Controller, d'un ou plusieurs CAS Work et d'un CAS backup Controller (facultatif), chacun fonctionnant sur des machines
distinctes :
Notre objectif, et celui de cet article, est de disposer de deux serveurs CAS Controller, comme dans le schéma ci-dessous :
Maintenant que les présentations sont faites, parlons des conditions pour déployer 2 serveurs CAS Controller.
Conditions requises
Vous pouvez ajouter un serveur CAS à une machine qui n'héberge pas déjà le logiciel SAS Viya existant. Pour faire simple, vous ne pouvez pas utiliser le CAS controller existant pour en faire un second, ni un worker pour faire de lui un second CAS Controller.
Les serveurs CAS qui sont ajoutés à un déploiement SAS Viya ne peuvent pas être retirés sans supprimer l'ensemble de votre déploiement SAS Viya. Un point important qu'il faut garder en tête au moment de votre décision de partir sur deux CAS Controller.
Un environnement multi-tenant ne prend pas en charge plusieurs serveurs CAS par tenant (chaque tenant a un accès exclusif à un seul serveur CAS).
Dans les environnements SAS Viya qui ont plus d'un serveur CAS, le serveur CAS par défaut doit être en cours d'exécution (généralement, cas-shared-default). En effet, ce serveur CAS par défaut doit être en cours d'exécution même si un client utilise un autre serveur CAS, afin que certaines caslibs telles que AppData, ReferenceData et SystemData soient accessibles à partir du serveur CAS par défaut. Ces caslibs contiennent des données nécessaires à des applications telles que SAS Visual Analytics, qui dépend d'AppData pour les données cartographiques). Votre serveur CAS par défaut est défini dans la propriété de configuration sas.casmanagement.global.casServer.
Lorsqu'elle est correctement définie, l'option de serveur CAS cas.MAXCORES spécifie la limite du nombre total de cœurs physiques disponibles pour un serveur CAS. Pour plus d'informations, voir cas.MAXCORES.
Vous êtes limité à un contrôleur CAS ou à un contrôleur de sauvegarde CAS par machine.
Si vous ajoutez un serveur CAS distribué qui contient un contrôleur de sauvegarde, assurez vous que le contrôleur de sauvegarde et le contrôleur CAS (le contrôleur primaire) utilisent tous deux le même système de fichiers partagés. Pour plus d'informations, voir "Configurer un système de fichiers partagé pour les contrôleurs CAS" (post-déploiement).
Chaque machine sur laquelle vous installez un serveur CAS doit contenir le compte utilisateur (cas) et le groupe (sas) CAS. Pour plus d'informations, voir "Configurer le compte cas dans SAS Viya pour Linux : Deployment Guide".
Pour les déploiements de programming-only et les déploiements qui utilisent le groupe personnalisé CASHostAccountRequired, il existe une exigence supplémentaire pour les répertoires d'origine des utilisateurs. Dans ces deux cas, la caslib d'un utilisateur Casuser est mappée sur ~/casuser. Par conséquent, les répertoires personnels ($HOME) de tous les utilisateurs CAS doivent être partagés afin qu'ils soient accessibles à partir des machines du contrôleur et du contrôleur de sauvegarde. Le partage des répertoires personnels des utilisateurs garantit que le chemin d'accès à la bibliothèque CASUSER est disponible lors du démarrage de la session CAS.
Pour la plupart des autres scénarios de session CAS, la bibliothèque CASUSER est définie sur un chemin d'accès dans le système de fichiers partagés décrit dans la section "Configuration d'un système de fichiers partagés pour les contrôleurs CAS" (post-déploiement).
Ajouter un serveur CAS étape par étape
Rentrons maintenant dans le gros du sujet, à savoir l'ajout d'un second CAS Controller.
Pour ajouter un serveur CAS, suivez ces étapes :
Si vous souhaitez ajouter uniquement un nœud de travail CAS ou un contrôleur de sauvegarde CAS, reportez vous à la section "Convertir un serveur CAS SMP en serveur CAS MPP" .
Dans le cadre d'un déploiement uniquement programmé, veillez à faire une sauvegarde de votre fichier proxy.conf. Après avoir effectué toutes les étapes d'ajout d'un serveur CAS, ajoutez les informations du fichier proxy.conf sauvegardé au nouveau fichier proxy.conf.
Avant de commencer :
Avant de vous lancer dans l'ajout d'un second CAS controller, assurez-vous que votre système SAS Viya répond aux exigences que je décris au début de cet article. Vous pouvez également retrouver les prérequis pour ajouter un second CAS server sur le site du support SAS.
Lors de l'ajout à un déploiement SAS Viya existant, SAS télécharge et installe les derniers logiciels disponibles dans les dépôts de logiciels. Par conséquent, assurez-vous que vous utilisez un dépôt miroir existant afin de ne pas avoir un décalage de version entre votre CAS controller default et celui que vous allez ajouter.
Vérifiez que le serveur CAS qui est ajouté au déploiement a le nom d'hôte que vous attendez. Pour rappel, chaque machine du déploiement doit avoir un nom de domaine pleinement qualifié (FQDN). Pour être sûr que chaque machine du déploiement possède le nom d'hôte attendu, exécutez les commandes hostname, hostname -f et hostname -s sur chaque machine. Si l'une des machines n'est pas nommée comme prévu ou ne possède pas de nom de domaine complet, corrigez le problème et exécutez à nouveau les commandes pour confirmer la correction.
Les étapes de déploiements
Configuration
La première étape consiste, en toute logique, à vous connectez au serveur Ansible (là o* se trouve vos playbook Viya) en tant que compte utilisateur qui déploie le logiciel.
Ensuite, vous devez comprendre que chaque serveur CAS que vous souhaitez ajouter doit avoir ses propres fichiers vars.yml et inventory.ini.
La méthode recommandée pour gérer plusieurs instances de vars.yml et inventory.ini est de créer une copie de vos existants. Pour vous y retrouver, incluez le nom du serveur CAS dans les noms de fichiers de ces copies. Stockez ces nouvelles copies dans le répertoire du playbook.
Dans le répertoire sas_viya_playbook, je réalise une copie du fichier vars.yml que je nomme casserv02.vars.yml :
cp vars.yml casserv02.vars.ymlUne fois la copie réalisée, ouvrez ce nouveau fichier casserver02.vars.yml et localisez la section CAS CONFIGURATION. En dessous de casenv_user, ajoutez la ligne suivante :
casenv_instance: new-CAS-server-nameDans exemple, et comme dans la documentation SAS, je nomme mon instance server02 :
A noter que la valeur de casenv_instance est ajoutée au nom de base, cas-shared, pour former le nom de l'instance de votre nouveau serveur CAS. Dans mon exemple, le nom complet de l'instance de déploiement est donc cas-shared-server02.
Vérifiez chaque option de configuration du serveur CAS dans la section CONFIGURATION CAS, et mettez à jour chacune d'entre elles en fonction de la nouvelle instance du serveur CAS.
Comme je l'ai indiqué, chaque serveur CAS que vous ajoutez doit avoir son propre fichier inventory.ini. Aussi, comme vous l'avez fait avec vars.yml, faites une copie de votre fichier inventory.ini :
cp inventory.ini casserv02.inventory.iniDans un éditeur de texte, ouvrez votre copie du nouveau fichier inventory.ini (casserv02.inventory.ini)
Votre fichier contient donc vos machines "d'origine" pour le moment, ne touchez à rien. Laisser la liste telle quelle :
Supprimez les cibles de déploiement originales de tous les host group du fichier, à l'exception de [consul], [httpproxy] et [sas_all:children]. Ces trois groupes d'hôtes doivent contenir leurs entrées originales. Notez qu'un host group peut n'avoir aucune entrée sous lui. Mais, un groupe d'hôtes ne doit pas être supprimé, même s'il est vide.
Exemple :
Maintenant, ajoutez vos nouveaux Server CAS au début de votre fichier casserv02.inventory.ini :
Dans mon exemple ci-dessus, j'ai ajouté deux nouveaux serveur : viya35ctr2 et viya35wrk3.
Affectez les cibles aux host group requis. En suivant mon exemple, cela donne :
Vérifiez ensuite que les host group [consul], [httpproxy] et [sas_all:children] sont présents et qu'ils contiennent les entrées de votre déploiement SAS Viya initial.
Déploiement
Une fois vos deux fichiers de configuration créés, nous pouvons utiliser ansible-playbook pour déployer votre nouveau CAS Server.
Rendez-vous dans le répertoire sas_viya_playbook et lancez la commande ci-dessous :
ansible-playbook -i casserv02.inventory.ini site.yml -e "@casserv02.vars.yml"N'oubliez pas un point important, indiqué au début de cet article : vous devez avoir utiliser un dépôt miroir pour effectuer l'ajout d'un serveur CAS. En effet, lors de l'ajout à un déploiement SAS Viya existant, SAS télécharge et installe les derniers logiciels disponibles dans les dépôts de logiciels. Si vous n'avez pas utilisé de dépôt miroir , vous prenez le risque d'un décalage de version entre votre CAS controller default et celui que vous allez ajouter.
Vérification après déploiement
Dans un premier temps, vous pouvez vérifier visuellement la présence de votre nouveau CAS Controller directement dans SAS Environment Manager, comme dans ma copie d'écran ci-dessous :
La documentation SAS propose également de tester le fonctionnement du nouveau CAS Controller avec Gridmon, comme dans l'exemple ci-dessous :
Si vous souhaitez lancer Gridmon, rendez-vous dans le répertoire /opt/sas/viya/home/SASFoundation/utilities/bin/ sur l'un de vos serveur CAS Controller puis exécutez la commande gridmon.sh
/opt/sas/viya/home/SASFoundation/utilities/bin/gridmon.shVidéo
Je vous propose également une vidéo, disponible sur Youtube si vous souhaitez voir l'ensemble des opérations présentes dans cet article.