Bene, buongiorno a tutti e benvenuti a questo che è il decimo appuntamento di questi Techub che ci hanno accompagnato nell'ultimo nell'arco dell'ultimo anno. Oggi andremo a parlare di un argomento molto interessante dal mio punto di vista perché parliamo di tutto quello che è possibile automatizzare e quindi della TESC Automation e con me sarà ci sarà Andrea Tosato che come al solito farà prima una breve spiegazione, poi andremo live con una demo. E buongiorno anche te Andrea. >> Buongiorno. >> Buongiorno. >> Buongiorno. >> E vi ricordo che potete fare tutte le vostre domande nell'apposita sessione domande e risposte e noi le guardiamo e risponderemo a tutte alla fine della presentazione o della demo indipendenza un po' dellanumerosità. Io adesso mi zittisco e lascio completamente lo stage ad Andrea. >> Buongiorno a tutti. Però oggi parleremo di un argomento indubbiamente molto tecnico, ma allo stesso tempo molto importante per migliorare quello che è l'efficientamentoe l'affidabilità delle nostre attività anche quotidiane che andiamo ad effettuare all'interno della nostra infrastruttura IT che è relativa al concetto di automatizzazione. Allora, in questa presentazione andrò a fare una introduzione, una breve overview su quello che è una tecnologia, una piattaforma che è Ensible, come Ensible si integra con le soluzioni netap e poi farò vedere una demu proprio per far toccare un po' con mano quello che è effettivamente il risultato e ciò che si può ottenere con utilizzando una tecnologia commensible. cosa significa orchestrare determinate operazioni. E la demo sarà basata sulla creazione di una soluzione NAS storage basata su una nostra tecnologia onp eh la stessa demo poi mostrerà come replicare in un ambiente Disaster Recovery la stessa soluzione NAS per poterlo poi testare ai fini appunto di verificare il buon funzionamento dell'ambiente Disaster Recovery. tutte operazioni che tipicamente vengono effettuatecreando questi ambienti manualmente. Ecco, in questa demo vedremo come tutto questo possa essere automatizzato e vedremo quali sono i benefici che questo può comportare. Allora, direi di partire appunto col concetto di base. L'idea di orchestrare, di automatizzare le operazioni che vengono effettuate all'interno di un data center, ma vedremo che la stessa tecnologia può essere utilizzata anche per le applicazioni in cloud, è quella di evitare laddove possibile e ridurre poi i tempi di quelli che sono processi tradizionalmente effettuati manualmente, ovvero ho un'attività o un'operazione da effettuare all'interno della mia piattaforma. Prendiamo lo storage, ovviamente come riferimento nel caso della nostra tecnologia, laddove io debba creare un nuovo servizio NAS, un nuovo servizio SAN, creare un nuovo file system per un progetto specifico. Tutte queste operazioni venivano richieste manualmente a uno specialista, al all'amministratore dello store stesso, il quale doveva prendersi in carico il task, l'attività e ovviamente eseguirla. Tutto questo aveva un tempo, un tempo per effettuare la richiesta, un tempo prima che la richiesta fosse presa in carico e ovviamente un tempo di esecuzione.L'uso di uno strumento come Ensible, unchest un orchestratore in generale permette di automatizzare questo processo, ovvero il richiedente, l'operazione può attivare, innescare quella che è tutta l'operazione orchestrata e avere ottenere il risultato, cioè l'esecuzione di questa attività in tempi molto rapidi, nonché con tutti i vantaggi relativi al fatto che un'operazione automatizzata è decisamente molto meno soggetta al rischio di un errore, il tipico errore umano che un'operazione anche effettuata da uno specialista effettuata magari tantevolte nell'arco dell'anno, perché ovviamente l'orchestrazione ha molto senso sull'automatizzare quelle che sono le operazioni ricorrenti, anche uno specialista quando una certa attività la ripete un centinaio di volte, se non un migliaio di volte durante l'anno, il fatto di incorrere in un rischio di errore può essere elevato. prima o poi si sbaglia per l'appunto. Automatizzare questa operazione riduce al minimo questo tipo di errori. Abbiamo preso Ensible come riferimento. Ensible è un automation engine perché NETAP effettivamente ha un po' eh sposato, adottato questo questa tecnologia. È dal 2018 che Netap ha sviluppato quelli che sono i moduli ensible, ovvero la sua piena compatibilità, eh sviluppandoli in primo luogo per la piattaforma HNTAP, che è quella più largamente diffusa ovviamente nelle nostre soluzioni NETAP, ma oggi adottandola e adeguandola anche a tutte le altre soluzioni, sia a quelle in cloud, presenti in Amazon, Google Azurem, ehm che per la piattaforma ad esempio oggi storage chiamata storage Quindi ormai l'adozione di Ansible è assolutamente diversificata un po' su tutte le piattaforme Netup. Oggi vedremo una demo mirata sulla piattaforma Ontap, ma tutto quello che vedremo può essere poi riportato adottandola a qualunque delle nostre tecnologie. Ensible è una soluzione assolutamente gratuita, una piattaforma gratuita eh che prevede l'installazione di un ambiente Python dietro, quindi tipicamente si installa un ambiente Python e sopra si installa la piattaforma Ansible. Ripeto, tipicamente gratuita, praticamente gratuita. Eh, i moduli di Netup erano all'inizio parte integrante della soluzione Ensible. Dopodiché, dato che molti brand, come vedete, Ensible non è ad uso Netup, ma di fatto tutti i brand hanno adottato dei loro plugin, una loro integrazione con Enbor, quindi che va dal networking, piuttosto che la virtualizzazione con Vienware e questo permette quindi di orchestrare ambienti molto ampi e quindi non solo mirati al allo storage. Avendo adottato Ensible e avendo aggiunto moduli Ensible, il fatto di integrarli nativamente in Ensible diventava troppo oneroso dagestire, nel senso che diventava il tutto moltogrande e quindi Ensible ha introdotto il concetto di collection, cioè ha esternalizzato tutte le componenti relative a un brand e le collection possono essere scaricate individualmente. queste librerie, per l'appunto, eh relative al singolo apparato, al singolo dispositivo, alla singola piattaforma che noi vogliamo automatizzare. Quindi il Netap ha rilasciato in maniera totalmente open source su Gitab le proprie collection. Quindi l'adozione di Ensi è assolutamente gratuito per qualunque cliente voglia provare a ad orchestrare le nostre soluzioni. E l'ETP stessa l'ha adottato anche a livello di servizi professionali, nel senso che la configurazione delle nostre piattaforme e anche le nuove installazioni nostre piattaforme, i servizi professionali vanno ad adottare l'uso di ensible proprio per velocizzare e ridurre i rischi di errore. l'ado adozione delle best practice, quando voglio configurare un qualunque ambiente, laddove venga orchestrato riesce a migliorare, a massimizzare, per l'appunto l'adozione delle best practice perché io posso codificare l'uso delle best practice grazie a un automation engine comeun po' di vantaggi e li provo ad elencare, quelli che ho già detto. Chiaramente orchestrare una qualunque attività, una qualunque operazione è molto più veloce che effettuarla a mano. Anche un esperto che riesce rapidamente acreare nuovi ambienti, a deployare nuovi ambienti, non può avere un confronto laddove io vado a lanciare quello che vedremo si chiama playbook, ovvero un processo automatico di creazione di un nuovo ambiente. En è open source, quindi di fatto non crea un login su una tecnologia perché tutto ciò che io definisco insible poi lo posso portare. è disponibile sia per piattaforme Microsoft che per piattaforme Linux ed è veramente molto portabile e nonprevede un login specifico su una tecnologia e ehm eh diciamo così un automation engine è di fatto un linguaggio, per usare un termine un po' inappropriato, ma di facile intendibilità è un linguaggio di scripting, ma è un linguaggio di scripting molto semplice. molto elementare e quindi lo rende veramente molto semplice da utilizzare anche a chi non ha un background di sviluppo di codice perché di fatto, lo vedremo subito dopo, la definizione di un playbook prevede di eseguire in sequenza delle operazioni. Quindi Ensible non è un linguaggio strutturato, non ha cicli, non ha condizioni, è molto semplice. Di fatto per creare un Playbook ansible io vado a eseguire in sequenza esattamente le stesse operazioni che da specialista andrei a eseguire a mano per creare un nuovo ambiente. Quindi prendo esattamente uno a uno le operazioni che effettuerei a mano e le elenco sotto forma di macrocomandi in un playbook canible per poi poterlo eseguire. L'orchestrazione è affidabile, nel senso che quando io ho definito un processo orchestrato e questo processo funziona, è evidente che la sua esecuzione, anche decine o centinaia di volte, andranno a buon fine, esattamente come sono andate a buon fine la prima volta. Quindi si riduce davvero al minimo il fatto che l'esecuzione di un processo orchestrato possa andare in errore o possa intredurre introdurre degli errori. Inoltre Ansible ha questo enorme vantaggio di essere agentless, ovvero io insto la piattaforma Ensible su una macchina tipicamente virtuale a corredo del mio ambiente ITe la piattaforma Ensible interroga ed esegue i comandi direttamente via chiamate API address rest verso i dispositivi che voglio orchestrare. Quindi non devo installare alcun agente, alcuna componente software direttamente sui dispositivi. Voglio automatizzare la configurazione e lacreazione di nuove ambienti sullo storage piuttosto che sul networking o sugli ambienti di virtualizzazione. Semplicemente questi vengono interrogati. Netap ormai ha rilasciato le APREST su qualunque nostra piattaforma e siamo partiti da una condizione in cui le API erano proprietarie netup. Oggi con le ultime release abbiamo trasformato, abbiamo di fatto completato la eh il porting e la trasformazione di quelle che sono tutte le API a trest con lo standard https per poter essere interrogate. Quindi utilizzare le A3 staccate TPS significa usare un canale sicuro, cifrato, autenticato per ogni singolo comando che vado ad eseguire e quindi di fatto la sicurezza è davvero adalti livelli e ovviamente la velocità, ma questo, ripeto, vien da sé col fatto che stiamo automatizzando dei processi che tipicamente sono paragonati ai tempi di un'esecuzione manuale, quindi sono decisamente molto veloci, ma lo vedremo nella demo. un breve glossario, giusto per avere ben chiaro i tre termini che userò durante poi il resto della presentazione, che sono quelli di moduli. I moduli inansible sono di fatto i comandi che io vado a ad eseguire. Il termine è proprio quello di modulo. Di fatto il modulo è il singolo comando che eseguo all'interno di uno script di un playbook ansible e sono macrocomandi. Questo è un vantaggio, una grossa diversificazione rispetto ai tipici linguaggi di scripting dove di solito andava a dover gestire i microcomandi, i singoli microcomandi e questo rendeva gli scritti molto lunghi e molto onerosi poi da gestire nel tempo, da fare manutenzione maintenance di questi scripting. Consible il problema è ridotto anche in questo caso al minimo perché di fatto ogni comando è macroscopico, ovvero faccio un esempio nel nostro contesto. Voglio creare un nuovo volume, ho il singolo comando che mi permette di creare il nuovo volume, ma anche la creazione di uno storage virtuale. Ho il singolo comando che mi crea un nuovo storage virtuale. Quindi, macroscopicamente, con un elenco di pochi comandi, vado già a creare unambiente complesso elencando pochicomandi macroscopici e per l'appunto nel mondo Ensible prendono il nome di modu. Il playbook è il nostro script, sempre abusando di questa parola, il playbook è ciò che noi andiamo ad eseguire, per l'appunto, per effettuare l'automatismo. Quindi il playbook è ciò che noi scriviamo, è il codice che noi andiamo a scrivere e ripeto, non è altro che un elenco sequenziale di comandi, ovvero i moduli che ho appena citato. Di fatto per scrivere un playbook cosa si va a fare? Tipicamente vado ad eseguire a mano tutta una serie di operazioni che pongo cheportano a compimento il mio obiettivo. Li elenco e vado a trovare il modulo corrispettivo di ogni singolo comando che vado ad effettuare. Ogni comando, sempre nel gergo di ensible prendo il nome di task. Quindi vado ad elencare questi task, trovo il modulo corrispondente che mi esegue il task e li vado ad elencare. Ensible quando eseguirò il playbook andrà ad eseguirmi uno per uno in sequenza tutte queste operazioni, ovviamente poi dandomi un risultato e portandomi a buon fine il tutto. I moduli sono i singoli comandi, diciamo il comando atomico, il comando più piccolo che io ho a disposizione e Ensible mette a disposizione anche quelli che sono i ruoli. Anche qui una mia definizione, diciamo così. Il ruolo non è altro che ehm di fatto un playbook già messo a disposizione all'interno della libreria delsingolo brand per effettuare attività complesse che di fatto vengono tipicamente vengono richieste regolarmente e quindi anziché scrivere tutte le volte dei playbook ad hoc penso per l'appunto alla creazione di un nuovo ambiente storage NASO Sun. Ecco, questi sono dei piccoli playbook che già prevedono tutta una serie di comandi, sono messi a disposizione e vengono chiamati ruoli, ovvero dei playbook, ripeto, già pronti per eseguire attività complesse. Quindi un ruolo mi permette di adottare già rapidamente Ensi laddove io non abbia ancora un mio repository a disposizione perché sono per l'appunto delle operazioni già messe a disposizione all'interno dellalibreria di Ensible. Cosa posso fare con Ensible? di fatto tutto. Netap ha una libreria ricchissima, ripeto, si chiama Collection, una libreria ricchissima di moduli, ovvero di comandi già messi a disposizione per poter fare qualunque cosa, quindi la configurazione infrastrutturale,eh la il tuning di questa infrastruttura, l'adozione poi di tutte quelle che sono le best practice, l'uso del quality of service, creazione di stories virtuali, le repliche, tutto quanto. Di fatto ciò che io posso fare a riga di comando manualmente lo posso orchestrare o un corrispondente modulo che mi possa effettuare quell'operazione. Quindi si possono fare attività infrastrutturali, attività di configurazione, di best practice, nonché poi automatizzare tutte quelle attività come la creazione di un Disaster Recovery e l'esecuzione, quindi la messa in produzione di un ambiente Disaster Recovery, che è la classica attività che tipicamente viene effettuata in emergenza. e quindi rispettando delle regole di solito codificate in un manuale. Ecco, l'idea è di trasporre quella che è la codifica di un manuale d'uso, come ad esempio l'attivazione di un best practice, codificando invece un playbook che mi esegue esattamente le stesse operazioni che io avevo definito nel manuale direttamente orchestrandole e questo mi riduce al minimo il rischio di errore perché fare le attività come attivare un DR in situazioni di emergenza può portare a rischio di errore che ovviamente ha la sua esecuzione moltorapida, quindi riducendo quello che è poi l'err RTO e la ripartenza di un disaster recovery. È tutto disponibile su ambiente open source, quindi sia direttamente su Galaxy Ensible Galaxy, che è il portale in cui sono presenti tutte le collection dei vari brand e qu ovviamente lo screen quella che è la collection, nonché su Gitab, perché Netap ha sviluppato tutta la libreria e messa a disposizione per l'appunto come codice open source, per cui è possibile andare su Gitab escaricare l'intera collection. si installa con un unico comando che è ensible galaxy install. Ontap, se vogliamo installare la collection relativa ad Ontap, ma abbiamo anche tutte le altre collection, anche quelle relative a elemento S, piuttosto che a agli series, quindi a Santricity, nonché aStorage Grid. Per quanto riguarda l'OB storage, abbiamo introdotto più di recente, ripeto, quelle anche relative alle soluzioni cloud EWS, Azure e Google, anche loro sono disponibili. si vanno ad installare quindi le collection che si vuole adottare, utilizzare. adottare, utilizzare. adottare, utilizzare. Netaportal'uso diEnsible attraverso dei canali community, quindi abbiamo un canale su Slack assolutamente libero a chiunque. Ci sono sempre persone dell'engineering netupp all'ascolto, per cui qualunque domanda relativamente all'uso dei singoli moduli ensible o qualunque problema relativo ai vari playbook sviluppati può essere rivolta direttamente in community. L'ho usata diverse volte e i tempi di risposta sono molto rapidi. Ripeto, c'è sempre qualcuno del dell'Engineer in ascolto su questi canali e sono persone molto esperte. Saltiamo direttamente su quello che è un esempio di un semplice playbook. Ripeto, la questione è molto tecnica, ma di per sé per chi ha un po' di dimestichezza col con l'uso del codice, eh tutto èanche abbastanza semplice. Questo è lo scheletro di un semplice playbook che ha un'intestazioneabbastanza standard dove si definisce quali sono gli host su cui io vado ad eseguire il playbook, gli si dà un nome e in una prima sezione di variabili vado ad elencare tutti quelli che sono i parametri che vengono richieste all'interno del playbook. L'idea è questa, io devo eseguire una serie di operazioni che, ripeto, tipicamente eseguo a mano e mi metto nella condizione di eseguire queste le operazioni a riga di comando, ad esempio nella command line del nostro ambiente storage. In command line avrò dei comandi da eseguire, comandi che sono composti dal comando stesso e ovviamente da tutta una serie di parametri. Il comando per cui voglio creare un nuovo volume avrà tra i parametri, ad esempio, il nome di questo volume e la dimensione di questo volume. Ecco, tutti questi parametri ovviamente vengono riportati sotto forma di variabili all'interno del playbook.In questo esempio le variabili sono elencate all'interno dello stesso playbook che io sto eseguendo. Ma eh quando io vado a sviluppare da un punto di vista pratico un playbook, di solito si tende a disaccoppiare il playbook che corrisponde all'elenco di operazioni da eseguire con quelle che sono le variabili che tipicamente vengono scritte in un file a parte in modo appunto da disaccoppiare il playbook che rimane sempre lui, cioè l'elenco di operazioni da eseguire. dalle variabili che possono essere modificate, cambiate, adattate ogni volta che io eseguo questo playbook. Ovviamente se ho tanti volumi da dover creare,il plag rimane lo stesso, che è quello che mi permette di creare un nuovo volume, ma vado a modificare ovviamente i parametri, i nomi di tutti i volumi che voglio creare e le dimensioni specifiche che ogni volume che devo creare ovviamente richiede. Quindi una prima sezione relativa alle variabili, in questo caso interno, ma tipicamente vengono esternalizzate in un file esterno. le collection, ovvero le librerie che intendo utilizzare all'interno del playbook e in questo semplice esempio usiamo la nostra, quindi etap ontap specifico per la piattaforma HTAP. E qui comincia il playbook vero e proprio, cioè nella sezione task vado ad elencare come una lista il meno vado ad indicare il formato è quello yamel per chi dimestichezza con questo formato. Un elenco di task da eseguire, un task che è un nome che funge un po' anche da commento, cioè ogni task eseguo un'operazione ben precisa e nel nome vado a spiegare qual è quell'operazione ben precisa che io voglio eseguire. Il nome del comando è na onta volume è proprio il comando, è il modulo che io trovo nella mia libreria, nella mia collection e nella documentazione soprattutto che mi spiega che il modulo na on tab value ha tutta una serie di parametri necessari richiesti mandatori piuttosto che opzionali per poter essere eseguiti. Ma in questo esempio ve andrò molto velocemente, lo stato lo spiego dopo. Per creare un volume, che è il mio obiettivo, mi serve il nome di un volume, il nome del V server, ovvero dello storage virtuale dove voglio creare, ovviamente l'aggregato dove voglio creare e ancora più ovviamente la dimensione di un volume. Quindi, di fatto, sono proprio i parametri essenziali che io userei a riga di comando, nonché anche da interfaccia grafica, perché se devo creare un nuovo volume, anche da interfaccia grafica, questi queste informazioni in una forma online mi vengono richieste dove voglio crearlo e che nome ha e che dimensione.E come avevo già accennato, qualunque comando ensible, qualunque modulo ensible per poter essere eseguito dalla piattaforma deve essere autenticato e quindi vengono riportati sempre anche lost name, cioè dove voglio eseguire chi mi esegue il comando, cioè il mio storage e la login username e password, nonché la metodologia https, cioè il canale di comunicazione che voglio utilizzare e nel caso io abbia anche un certificato, posso valutarlo. Questo per migliorare, aumentare la sicurezza sul sulla comunicazione, anche un certificato. Quindi la questa è un po' la struttura di un semplice playbook, un'interestazione e un elenco, in questo caso è un unico comando, ma può essere un elencoale di comandi. due concetti abbastanza importanti che riguardano Ensible, che un po' lo caratterizzano, è quello per cui io definisco, come nell'esempio che ho appena citato, un semplice playbook per creare unnuovo volume e la creazione, il fatto che io voglio creare un nuovo ambiente è indicato dallo stato. lo stato che è associato alla quasi totalità dei moduli che io vado a richiamare,nel caso sia presente, va ad indicarmi proprio un po' come una macchina stati, effettivamente il fatto che al termine dell'esecuzione del mio comando io voglio trovarmi in uno stato per cui ciò che ho richiesto debba essere presente. Cosa ho richiesto? la creazione di un volume. Molto bene. Se lo stato è presente, Ensible fa sì che al termine dell'elaborazione di questo modulo, di fatto al lancio alla chiamata di questo modulo, il volume con le caratteristiche che ho indicato sia presente. Di fatto vado a crearlo, lo vedremo a destra. Se io voglio cancellare un volume, perché Ensible si occupa di creare, ma anche di decommissionareehm le installazioni, le operazioni, se io voglio cancellare il mio volume, io vado a richiamare il modulo tale quale come l'avevo utilizzato in fase di creazione, ma vado a cambiare lo stato. Lo stato in questo caso sarà assente, ovvero vado a dire al termine dell'esecuzione del mio comando on tap volume, vai a cancellare. io non voglio avere il volume di riferimento. È molto efficace questa mh questa modalità perché mi permette di mantenere lo stesso playbook che va a creare nuovi ambienti e utilizzare lo stesso playbook anche per decommissionare laddove io vado a creare un volume dicendogli lo stato finale è il volume deve essere presente allo stesso modo lo stato finale del volume assente va a cancellarmi il volume e questo vale per tutto. nuovi storage virtuali, nuovi indirizzi IP, nuovi servizi NASO SAN, nuove Lun, così come le creo con lo stato di presente, vado a decmissionarle con lo stato di assente. Il playbook rimane di fatto inalterato e lo stesso è la stesso concetto posso applicarlo alle modifiche. Ho creato un volume, in questo caso da 10 GB, nel tempo voglio modificare la sua dimensione, portarlo ad esempio a 20 GB. io vado a rieseguire lo stesso playbook che mi aveva creato il volume andando a modificare solo i parametri, quindi quel file tipicamente esternalizzato in cui eh riporto tutte le mie variabili con i loro valori. Rieseguo il playbook con variabili diverse, quindi con parametri diversi, e vado ad effettuare modifiche nel mio ambiente. il volume è creato con 10 GB. In questo caso basta cambiare il size a 20 GB e la riese del modulo Hupp volume mi va, dato che il volume esiste già, a modificare semplicemente il parametro di dimensione e miende il volume. Questi dueconcetti molto semplici ma moltoimportanti di Ensible.Da qui, visto che ho parlato solo di >> Sì. No, nel senso che siamo già a 27 minuti, perché senò non riusciamo a stare nei riusciamo a Grazie. Perfetto, grazie Roby. Una breve digressione. Abbiamo parlato di Ensi come playbook che va codificato, ovviamente codificato ariga di comando con un editor di codice, ma un concetto importante è che se è vero che mi richiede una conoscenza specialistica per scrivere un playbook, perché io devo sapere ovviamente devo avere le competenze per poterlo scrivere, quindi competenze di codice e competenze di tecnologia, in questo caso Netap per sapere esattamente quali operazione è necessario effettuare per ottenere l'installazione, la creazione di un nuovo ambiente, ad esempio, ma Ensible mette a disposizione anche un'interfaccia grafica che è a pagamento chiamata Ensible Tower, ma ne esiste una sua versione gratuita che invece si chiama Ensible AWX, quindi liberamente scaricabile, che mi permette quindi di avere di mettere a disposizione anche per utilizzatori dei Playbook che non abbiano competenze specifiche. Quindi l'idea è fa scrivere ilcodice dell'orchestratore a chi ha competenze, allo specialista, ma poi mettere a disposizione questi playbook che mi eseguono queste operazioni di creazione nuovi ambienti anche a persone che non hanno competenze specifiche. un team che ha delle persone di operation che si occupano di creare nuovi volumi e mettere a disposizione nuovi servizi all'interno deldata center o dell'ambiente cloud, possono andare a richiamare i playbook che sono stati precaricati in questa interfaccia grafica senza averne competenze, semplicemente vanno a lanciare i playbook. Questo è Ensible AWX, quindi l'interfaccia grafica gratuita che ha una semplice dashboard in cui sono elencati i playbook già messi a disposizione e vengono lanciati semplicemente cliccando su un'icona. Tutti i parametri che abbiamo visto sono tipicamente codificati all'interno del codice con l'interfaccia grafica possono essere compilati attraverso una semplice forma messa a disposizione. Quindi anche voglio creare un nuovo volume, il nome del volume, la dimensione del volume possono essere inseriti direttamente in un formine, quindi rende veramente molto semplice l'adozione poi di un playbook laddove è stato è stato già creato. Quindi qualunque tecnico di tipo è in grado di utilizzare un repository di playbook, di orchestrazione e in più, dato che i playbook tipicamente si occupano di effettuare operazioni macroscopiche, l'interfaccia grafica permette di creare una sorta di workflow diworkflow di operazione, cioè di concatenare più playbook tra loro per eseguire operazioni complesse e quindi che in sequenza vanno a richiamare più playbook. Questa è una breve digressione di più, non abbiamo tempo di andare sull'interfaccia grafica, per cui ora possiamo direttamente saltare a quella che è la demo. Provo a condividere il mio schermo. Intanto ricordo, se avete delle domande, delle curiosità di utilizzare l'apposita sessione domande e risposte come state già facendo e risponderemo a tutti alla fine. >> Perfetto. Allora, intanto cheaccedo alla condivisione dello schermo che Ok, eh vado a descrivermi un po' quello che andremo a vedere con la demo. La demo avrà sarà l'esecuzione di alcuni playbook. Il primo andrà a crearmi un nuovo ambiente NAS virtuale, quindi metterò a disposizione un nuovo storage virtuale ad uso F sharing con il proprio indirizzo IP, il proprio nome, la join al dominio e un altro playbook andrà ad replicarmi tutto per crearmi un disaster recovery. Quindi, appunto, l'idea di automatizzare la replica totale di questo storage virtuale, quindi il suo nome, sui P verrà tutto replicato, tutti i volumi, le share e le policy di snapshot, ad esempio, verranno replicate su un secondo ambiente.E infine, se avremo il tempo, eh vedremo anche come clonare un ambiente disaster recovery per effettuarne i test. Tipicamente quando regolarmente come clienti dovete testare un ambiente disaster recovery per vederne il suo funzionamento, anziché andare a lavorare sull'ambiente disaster recovery vero e proprio, è possibile lasciare inalterato quell'ambiente esas recovery, in modo ad esempio che le repliche che vengono effettuate dalla produzione con tempistica regolare del quarto d'ora, dell'ora di lineamento continuano a lavorare e noi effettuiamo un test di disaster recovery clonando tale quale il mio disaster recovery il nostro recovery per poterlo testare. Questo è un po' il giro della demo. Non riesco a vedere se è disponibile il mio schermo. Eh sì, direi di sì. L'esecuzione del primo playbook, ovvero la creazione della NAS, non andremo a vedere il codice, ma riporto quelli che sono i sei task che verranno eseguiti all'interno del playbook per poter creare una NAS. sono esattamente le operazioni che io andrei ad eseguire manualmente per creare una nuovo ambiente NAS, ovvero la creazione di un nuovo storage virtuale, la configurazione del DNS per poter ovviamente risolvere i nomi all'interno di questo di questa NAS. Assegneremo un nuovo indirizzo IP, cioè la creazione di una logical interface all'interno dello storage, la join al dominio di questa nuova NAS, la creazione di un volume e la creazione di una share. Le sei operazioni che cre che mh dovrei effettuare manualmente lo andiamo ad automatizzare con l'esecuzione delnostro playbook. Gli ambienti di lavoro sono due eh storage on ttap, in questo caso gli ontap select, cioè gli ontap virtuali. Vado a loggarmi sui due sistemi. Il primo ambiente è quello di produzione chiamato cluster A, che come vedete è vuoto, non ha alcuno storage virtuale, un ambiente pulitissimo chiamato cluster A di produzione e su ambiente di disaster recovery che anch'esso ovviamente è vuoto. Partiamo dall'ambiente di produzione. Questa è la mia console Ensible dove ho attivato un virtual environment Python. Ho un elenco di Playbo da eseguire 01 02 03 04. Il primo è quello che mi crea la NAS virtuale. L'esecuzione è molto semplice, Ensi Playbook e il nome del playbook 01. Questa è la sua esecuzione. Davanti all'esecuzione adesso aggiungo il comando time per vedere in quanto tempo Ensible è in grado di crearmi una nuova NAS virtuale. Come ho fatto vedere prima, le operazioni sono sei. Di fatto deve creare un nuovo torret virtuale e tutte quelle sei operazioni, nuovo volume, nuova share che a mano impiegherei all'incirca un quarto d'ora da esperto. Impiegherei un quarto d'ora a compilare le form di creazione di queste cose. Conensible, andiamo a eseguire il playbook. mi esegui in sequenza tutti i task, create new SVM, setup DNS, create data, la join al dominio che richiede un po' di secondi per essere effettuato, la creazione del nuovo volume, la creazione della share, queste sei operazioni che manualmente mi porterebbero via circa un quarto d'ora con l'orchestrazione mi hanno portato via, come si può vedere qua, solo 12 secondi di esecuzione. Quindi l'orchestrazione di questa attività veramente riduce i tempi in maniera impressionante. E cosa ottengo sul mio cluster di produzione? Eccola qui la mia nuova NAS, il mio nuovo storage NAS con il suo volume data e la sua share che si chiama come il volume, quindi una share data. Questo per l'appunto in tempi moltorapidi. Dovreste vedere quindi anche questa macchina Windows su cui io posso andare a ehm a vedere che effettivamente la share è stata creata, il tempo a disposizione è veramente poco, per cui proviamoavedere molto rapidamente se accedendo a questa NAS che si chiama SVM NAS io ho il mio volume, la mia share a disposizione che è volata ovviamente nuovo, quindi vuoto. provo a creare a copiare all'interno di questa share una cartella la quale ha dei file già e sottocartella a disposizione. Questo per vedere che l'ambiente di produzione è stato creato in 12 secondi e ovviamente funziona perfettamente. Ritorno alla mia piattaforma. Come vi dicevo, lo scopo è anche quello di creare un ambiente di disaster recovery e io qui ho il mio playbook già pronto, quindi create SVMDR, vado a lanciare un nuovo playbook, il quale mi andrà a creare in maniera automatizzatauna nuova storage virtual machine sull'ambiente Disaster Recovery e va andrà con Snap Mirror configurare Snap Mirror per replicare tutti i volumi del mio ambiente di produzione e tutte le share. Questo mi porta a dire un'altra cosa molto importante. Tipicamente i modulivanno a creare un qualcosa, no, a configurare un qualcosa, ma esistono dei moduli ensible, uno su tutti che si chiama Ontap Info, che è un modulo che invece va ad interrogare la mia piattaforma. Ontapinfo è un modulo che mi interroga lo storage, mi interroga un cluster netupp e mi restituisce tutte le informazioni di configurazione di quell'ambiente. In un playbook come la creazione di un disaster recovery è molto importante interrogare la mia produzione perché ovviamente mi dà tutte le informazioni per poter replicare il tutto su un ambiente disaster recovery. Quindi se voglio sapere quanti volumi di quanti volumi è composto uno storage virtuale con questo modulo on Tap info assieme a veramente una miria di informazioni mi restituisce l'elenco, la lista di tutti i volumi creati sull'ambiente di produzione per poterli ricreare per l'appunto in ambiente di Zasta Recovery. In questo caso avevo sette eh task da eseguire e sette task sono stati eseguiti. No, provo a spiegare come si legge il report finale di un playbook, perché indubbiamente è importante anche questo. Eh, in questo caso i task sono sette, le operazioni da eseguire sono sette e report finale mi dice che sono stati eseguiti con successo sette task, ok? sette task e che questi sette task ognuno mi ha composto, mi ha comportato una modifica del mio ambiente e quindi mi dice che sono state cambiate all'interno del mio ambiente sette cose. Ehm, mi veniva facile spiegarlo per la creazione della NAS. la NAS mi andava a creare una nuova storage virtuale, ma anche il Disaster Recovery mi crea una nuova storage virtuale. Quindi questo è un task che mi comporta un cambiamento, cioè il fatto di aver creato uno storage virtuale. Se io andassi a rieseguire questo modulo, otterrei che sette task sono stati eseguiti, cioè troverei sette ok qui, ma zero changed, perché se rieseguissi il playbook, tutte le cose che l'esecuzione la prima volta ha cambiato, ha creato, di fatto ovviamente non vengono più ricreate una seconda volta perché ci sono già e quindi andrei ad avere l'esecuzione ok di sette task, ma change zero. se eseguisse una seconda volta questo playbook, perché nulla verrebbe cambiato. Tutto ciò che è stato eseguito adesso ovviamente lo ritroverei. Un altro parametro molto importante è il failed. Quando un playbook viene eseguito correttamente, senza errori, come in questo caso, non ho nessun errore fail zero. Nel caso io avessi un errore, questo capita durante lo sviluppo di un playbook, otterrei failed uno o failed in base a tutti i task che non sono stati effettuati correttamente per l'appunto a fronte di un errore. Tipicamente sono questi tre eh parametri, queste tre report che vadoa leggere, quanti tasto ho eseguito e se ho avuto degli errori. Abbiamo creato un DR? Effettivamente sì, sul mio cluster B abbiamo un ambiente di disaster recovery effettivamente funzionante e anche qui io posso andare semplicemente andare a vedere che ricercando l'SVM DR SVM NASDR, il suo nome corretto. ottengo una replica tale e quale del mio ambiente di produzione. Voldati era il mio ambiente di produzione e Voldati mi ritrovo sull'ambiente Disaster Recovery. Essendo una replica al Disaster Recovery, tutto ciò che ho qui, che ottengo in Disaster Recovery, è disponibile ridonly. è disponibile ridonly, per cui io potrei provare a cancellare qualunque cosa, ma il sistema ovviamente mi restituisce un errore. È impossibile cancellare e modificare un ambiente di disaster recovery replic. Questo mi permette di accedere in maniera sicura, magari a ripristino, se io avessi l'elenco delle snapshot, a tutti i miei dati, in maniera sicura e senza il rischio, per l'appunto, di cancellare in maniera erronea qualunqueSkype. Vado a concludere. eh la nostra demo eseguendo l'ultimotask, l'ultimo playbook, che è quello che mi crea unambiente clone. Prima di fare questo, vado a allinearecon un'ulteriore replica di SN Mirror che va a prendere anche una nuova snapshot,eh il mio ambiente di produzione con il mio ambiente DDDR. Quindi di fatto prende una snapshot e va a effettuarmi una replica di snap Mirror. Ovviamente quello che trovo è rimane sempre una copia tale quale a produzione. Magari per vederla meglio vado a cancellare qualche file dalla produzione e vado a rieseguire questaoperazione. Quindi prendo una nuova snapshot e vado ad effettuare una replica di Snap Mirror. nel mirror che impiega qualche secondo ad andare a compimento, ma vedremo come qui a destinazione, per l'appunto avevo cancellato dei file in produzione e sono spariti ovviamente anche nel Disaster Recovery a seguito di questa schedulazione manuale a questo playbook che mi va ad innescare un allineamento di SN. L'ultimo playbook, quello che mi crea un clone del mio ambiente di disaster recovery e i fini del test del DR. Vado ad automatizzare anche questa operazione.Sono una manciata di task. Come vedete i Playbo sono abbastanza brevi, sono una manciata di tasche quelle poche operazioni che io effettuerei a mano. Le vado ad orchestrare tutte, ad interrompere la replica, quindi, perché sto clonando il mio ambiente disaster recovery e sul mio cluster B, cioè il mio clusteraster recovery, compare questa NAS clone che non è altro che il mio clone del disaster Recovery. Andiamo quindi a richiamare l'SVM NAS Clone e ottengo questa terza copia, diciamo così. In questo caso totalmente virtuale. Come sapete i nostri cloni non vanno ad usare nemmeno un byte in più all'interno dello storage per clonare gli ambienti di produzione. Un clone del mio ambiente Disaster Recovery. differenza qui lo ha fatto sulla base del primo snapshot, quindi si ritrova quello che era l'ambiente quando avevo preso il mio primo snapshot, cioè con tutti i file prima che li andasse a cancellare in produzione. A differenza del disaster recovery, che è una replica ridonly della produzione, il clone è una copia riden wright di una macchina virtuale e quindi in questo caso io posso andare a testare un vero e proprio disaster recovery, anche a fare modifiche dei miei file, nonché a cancellarli. In questo caso la macchina è accedibile in lettura e scrittura, quindi io qualunque modifica eseguo su clone, questa è una macchina assolutamente usabile. Lettura. assolutamente usabile. Lettura. Questoè quanto. Al termine del dell'esecuzione del mio test di disaster recovery, io ho già predisposto anche i playbook per cancellare i miei ambienti. Quindi Ensible Playbook, il 94 è la cancellazione dell'ambiente di DR. io lo eseguo e il sistema ovviamente va a cancellarmi, a pulirmi, a decommissionare il mio ambiente in questo caso. E con questo si conclude la demo, anche la presentazione. Vi pubblico un paio di link diritto, grazie a voi. >> Grazie. Andre Sì, >> intanto ci sono c'è qualche domanda Andrea, quindi magari iniziamo a rispondere. Allora, la prima è possibile evitare utenza password come metodo di autenticazione?No, l'utenza password è vincolante proprio perché le chiamate appre richiedonola l'autenticazione. Ovviamente è possibile usare, soprattutto per quanto riguarda la password, dei secret in modo tale che la password sia cifrata. Come detto tipicamente in file esterni, eh laddove si va a creare un file che contiene il valore di tutte le variabili, di solito se ne crea un secondo file specifico proprio per le password autentizione, il le quali possono essere cifrate come SCRP, quindi la cosa risulta sicura, quindi la risposta alla domanda è no, le password sono richieste perché ogni comando deve essere autentificato, ma eh possono essere cifrate. Chiudo proprio perché la demo andava a decommissionarmi l'ambiente diclone, come vedete è sparito anche lui. Ehm e ritorno alla la presentazione. Quindi un po' di link se vi servono. Se avete altre domande chiaramente. >> Sì, ci sono altre due domande, altre tre domande, anzi in realtà eh si potrà avere una copia del playbook, penso quello che hai utilizzato ovviamente ripulito da IPR. >> Sì, >> Sì, >> Sì, assolutamente sì. Questiplaybook che ho utilizzato li ho già pubblicati su Gitab. Anch'io ho un mio repository Andrea Tosato, Ball on Tap Playbook, on tap sample e sono pubblicati, quindi potete usarli come base di partenza, magari per sviluppare poi dei playw più articolati e sono messi a disposizione. Assolutamente.>> Ulteriore domanda. Il task viene eseguito sempre comunque per intero o c'è la possibilità di far cessare l'esecuzione al primo errore? Allora, a fronte dell'errore il playbook si interrompe automaticamente, quindi sì, eh l'idea è di definire dei playbook che mi eseguono poi delle operazioni macroscopiche ma atomiche, nel senso devo creare un nuovo volume, creo un playbook per il nuovo volume, devo creare, come in questo caso uno storage NAS, avrò un playbook che avrà come obiettivo di crearmi lo storage NAS, per cui ha senso che un playbook venga sempre eseguito dall'inizio alla fine a fronte di un errore, il plebus si interrompe. Vantaggio di Ensible è che una volta risolto l'errore io posso rilanciare il playbook senza preoccuparmi del fatto che io lo abbia già eseguito magari in maniera parziale, cioè che alcune delle operazioni siano già state eseguite proprio in riferimento a quel concetto di macchina stati, cioè al fatto che ogni modulo va comunque a verificarmi se la sua operazione è già stata eseguita, cioè devo creare uno storage virtuale, fare la gioina al dominio e crearmi un volume. Se avessi già creato uno storage virtuale, già fatta la join al dominio, ma è andato in errore la creazione di un nuovo volume, ecco, la riesecuzione dell'intero playbook non si preoccupa del fatto che io ho già creato lo storage virtuale perché lui lo verifica, sa che c'è già e quindi dà per eseguita quell'operazione. al dominio allo stesso modo e verifica è già presente nel dominio il mio storage virtuale, non si preoccupa che c'è già e quindi va avanti fino ad arrivare all'operazione che aveva dato l'errore che era la creazione del nuovo volume, la riesegue ovviamente portandola a buon fine si spera e andando poi avanti nell'esecuzione delplaybook. molto eh efficace questa cosa del della macchina stati di Ensible, cioè rieseguire il playbook anche se fosse già stato eh eseguito parzialmente. Chi ha dimestichezza con gli script vecchio stile sa che eseguire due volte uno script quando era già stato eseguito parzialmente di solito eh significa andarsi a cercare ulteriori errori, no? Creare lanciare uno script che mi crea un volume, se il volume c'era già tipicamente va in errore proprio perché lo trova già. Invece con Essibo questa cosa non avviene. >> Ottimo. Un'ultima domanda, eh, rispetto a US case che ci hai mostrato, ti viene in mente qualche altro use case potrebbe essere interessante? Allora, l'idea di fondo è quella di cercare di orcestrare il più possibile. È stato il cloud ad insegnarci che laddove io abbia bisogno di una nuova piattaforma, di un nuovo ambiente IT, io vado a cliccare su una formigurazione e si innesca tutto un meccanismo automatico che mi mette a disposizione al giro di secondi, minuti o comunque poco tempo un ambiente pronto all'uso. Ecco, l'idea è quello di riportare la stessa logica anche all'interno dei data center on premise, ad esempio, laddove invece storicamente tradizionalmente tutto prevede l'esecuzione manuale dei vari responsabili di infrastruttura di tutta una serie di operazioni, per cui molte cose si possono orchestrare. Ovviamente non ha molto senso orchestrare quelle operazioni che vengono eseguite di rado, magari poco critiche, e ha molto senso partire da tutte quelle operazioni che vengono eseguite regolarmente. Io tutte le settimane so che devo creare nuovi ambienti storaging, nel nostro caso perché ho nuovi progetti eh che vengono devono essere messi in produzione. È chiaro che queste operazioni se le vado ad automatizzare sgravo poi di tutto un tempo che prevede l'esecuzione ripetuta ditutta una serie di operazioni. Però l'esempio che vi ho mostrato è quello del Disaster Recovery, la classica operazione che si esegue raramente, si spera addirittura mai, però quando serve, vuoi per lo stress, vuoi per la situazione emergen emergenziale in cui ci si trova, il fatto di avere definito come codice tutte queste operazioni mi permette di eseguirlo rapidamente in maniera mirata. devo lanciare un playbook e di ridurre, l'ho detto all'inizio, il rischio di errori perché quando ho una serie di operazioni che devono essere effettuate fatte a mano, possono portare alrischio dell'errore umano. >> L'errore. C'è un'ultima domanda appena arrivata. Eh, le feo risposte sono allineate con la versione ontap corrente?Allora, io ho usato un Ontap 98, se non ricordo male, nell'ambiente HONTP select e esistono vari livelli di libreria le quali vengono rilasciate in maniera abbastanza frequente, quindi eh perché siamo in piena fase di porting da quelle che erano le API proprietarie chiamate Zapi a quelle che sono le API ATREST, quindi regolarmente rilasciamo nuove librerie che hanno migliorato il porto le APRES che sarà poi l'obiettivo finale di avere tutto sotto forma di AP3, per cui sì, Ensi è compatibile con l'ultimo ontap, ma ripeto che Ensible lo ha ne siamo compatibili dal 2018, quindi ormai abbiamo un buon ventaglio anche soprattutto di cioè soprattutto anche di ontap un po' datati perché spesso l'ontap in produzione rimane magari in versioni non proprio recentissime in produzione per diverso tempo, quindi è possibile usare ensible sia con versione di relativamente ente vecchie che ovviamente congli onap recolutamentesì, non ci sono particolari problemi di release.>> Ottimo. >> Ottimo. >> Ottimo. Ricordo ancora tutti i link che stiamo mostrando che è punto di partenza anche per trovare tutte le informazioni. Rimaniamo comunque a disposizione andre io per eventuali approfondimenti e se avete bisogno di ulteriori informazioni non c'è problema. Intanto vi ringraziamo per aver partecipato. Ringrazio Andrea per la presentazione e per la demo e come sempre questa registrazione verrà poi resa disponibile sulle TAP TV, quindi riceverete poi link. Grazie a tutti per la partecipazione. Grazie Andrea.