J'ai testé pour vous OWA - aka WFA - (Partie 1)

OnCommand Workflow Automation (aka WFA) est un outil ultra puissant, permettant de piloter son stockage NetApp avec une grande finesse. OWA intègre la suite OnCommand depuis plusieurs années et connaît un développement grandissant (Nous en avions déjà parlé ici)

 

L’automatisation, brique essentielle au développement d’un Cloud public, privé ou hybride, peut paraître un peu complexe à mettre en œuvre et est souvent synonyme de développement et de scripting difficile à maintenir. OnCommand simplifiant bien les choses, nous avions déjà réalisé il y a quelques années sur ce même blog, la mise en place d’un catalogue de service. Je vous propose, au travers de quelques billets, de poursuivre ce chantier et d’aller plus loin avec OWA ! Le but n’est pas de remplacer les formations ou bien la communauté très active, mais simplement de vous aider à mettre le pied à l’étrier. OWA, ce n’est pas compliqué, et d'ailleurs, je l’ai testé pour vous

 

Voici d’abord quelques liens qui vont nous aider :

 

Aller c’est parti ! Commençons simplement. je vous propose de faire un workflow qui:

  • automatise la création d’un SVM (baie de stockage virtuelle, aka vServer)
  • configure le réseau
  • crée un volume
  • ajoute l'accès NFS aux utilisateurs

 

Partons du principe que OWA est installé et configuré pour piloter un clustered Data ONTAP et que les accès RBAC sont positionnés( tout portail de service Cloud nécessite une sécurité forte des accès, ce qui est paramétrable dans OWA)

 

On se connecte à l’interface web : https://monServeurOWA/wfa/


Bien qu’un certain nombre de workflows existent déjà et peuvent bien dépanner, je trouve que la « vraie » puissance de OWA est de faire un workflow « custom » qui réponde exactement à ce que l’on souhaite faire.

 

Pour cela on choisit le menu « Designer », rubrique « Workflows » puis « New »

On remplit les différents champs puis on va dans l'onglet « Commands »

 

Avant de se lancer dans un workflow complet avec de multiples actions, il faut bien définir ce que l’on souhaite faire et cibler le but à atteindre. Une fois le design réalisé nous allons utiliser les commandes présentes dans WFA et validées par NetApp. Bien que la liste des commandes doive répondre à toutes vos manipulations de Data ONTAP, rien ne vous empêche de créer vos propres commandes en Perl ou en PowerShell. Là encore, ZEDI peut vous aider.

Si on décompose notre workflow en commandes unitaires présentes dans OWA, voici ce que ça donne :

  • Création et configuration réseau d’un SVM
  • Setup du service NFS du SVM créé à l'étape précédente
  • Création d’une politique d’export
  • Création d’un volume utilisant la politique d'export créée

Naviguez dans la liste pour parcourir les différentes commandes. La description détaillée de chacune d'elles est disponible dans « Designer », rubrique « Commands ».

Ici on utilise des commandes « cm_storage » destinées à cDOT. On les met dans l'ordre d’exécution de notre workflow

 

On retrouve la trame de notre workflow

Maintenant nous allons configurer notre workflow en paramétrant chaque commande. S’il y a une subtilité dans OWA, à mon avis elle est là En effet, pour chaque champs on peut soit :

  • Mettre une valeur en « dur » : Elle sera mise entre guillemets simples
  • Faire une sélection parmi un choix multiple : le choix des valeurs est imposé par l'auteur de la commande
  • Faire une sélection automatique suivant des filtres et des règles. C'est l'auteur de la commande qui vous l'impose
  • Laisser le choix à l’utilisateur du workflow (user input). On précédera le nom de la variable d'un $

 

Commençons par configurer notre SVM. On clique sur le rectangle en dessous de « Create and configure Storage Virtual Machine »

On choisit par exemple ici, de faire  uniquement du NFS , de configurer les IP des DNS ainsi que le nom de domaine de façon statique. Le Nom du SVM sera indiqué par l'utilisateur : on donne donc un nom de variable : $NomDuSVM.

 

Le champs précédés d"une puce verte « R » indique un champ « référence ». Ici par exemple, le nom du cluster doit faire référence à un élément connu de la base OWA (en d'autres termes, il doit s'agir d'un cluster configuré pour être piloter par OWA). On ne peut donc pas entrer n'importe quoi !

On clique sur le carré «...» pour chercher le cluster. On peut le sélectionner selon différents filtres (ex : « Filter clusters by license » pour « Trouve moi un cluster disposant de la licence NFS » ou n'importe quelle règle de sélection qui nous intéresse). Comme je débute et que je ne souhaite pas trop complexifier mon premier workflow, on va faire simple : on va chercher le cluster par son nom ! Pas de risque de se tromper

 

Nous rentrons directement le nom du cluster. Ne pas oublier de le mettre entre guillemets simples !

 

Ensuite nous passons à l'onglet « Logical_Interface ». Nous créons une variable $IPduSVM pour permettre à l'utilisateur de choisir l'adresse IP. Le Netmask est fixé à 255.255.255.0. Là aussi, ne pas oublier les guillemets.

On voit ici qu'OWA nous propose les noms de variables déjà utilisés

 

Nous construisons le nom de l'interface réseau avec l'adresse « IP »_LIF. C'est un exemple. On aurait pu utiliser $NomDuSVM (dejà rentré par 'utilisateur) ou mettre un nom en dur pour que tous les SVM aient le même nom interface par défaut. C'est au choix selon vos conventions de nommage.


Le « home_port » est aussi une référence, nous sélectionnons une interface réseau physique par défaut, et toujours dans un souci de simplicité à ce stade, nous donnons le nom d'une interface en dur.

Nous finissons la configuration du SVM en indiquant la Gateway, le type de sécurité appliqué au volume « Root » ainsi que son nom. Ce dernier sera fait par construction d'une valeur entrée par l'utilisateur (le nom du SVM) à laquelle on ajoute « _rootVol ». Tous les SVM créés par ce worklow auront ainsi la même convention de nommage du volume « Root ».

 

Il est maintenant temps de tester la 1ère partie de notre workflow !

 

Le test d'un workflow s'effectue en 2 phases :

- Le test logique : on teste l'enchainement des commandes sans rien exécuter grâce à la commande « Preview »

- Le test réel : les commandes sont exécutées et nous pourrons constater le résultat.

 

Test logique

 

A l’exécution du workflow, une fenêtre nous demande de rentrer le nom du SVM et son IP. En fait nous renseignons ici les variables $NomDuSVM et $IPduSVM. On clique sur « Preview »...

... et tout semble correct ! Dans l'onglet détail, on voit par exemple la construction du volume Root « $NomDuSVM+'_rootVol' » qui donne bien « FasBloggers_SVM1_rootVol » dans notre exemple.

 

Test réel

 

L’exécution du workflow est lancé avec les mêmes entrées que lors de la phase de « Preview ». Nous testons un ping sur cette IP...

 

Au bout de quelques instants, l'IP pingue ...

 

 

...et le worflow est exécuté avec succès !

 

Une petite vérification dans System Manager permet de contrôler la création de notre SVM

 

Et voilà, nous sommes arrivés au terme de cette première partie en créant un workflow  automatisant la création SVM en fonction de son environnement réseau. Nous verrons dans une prochaine partie compléter la configuration en faisant référence aux objets déjà créés.

 

Pour les F@SBloggers, MRO