Gestione centralizzata di sistemi virtuali basati con Cloudmin (2° parte)
A questo punto era tutto pronto per scaricare un’immagine di sistema per il nostro Cloudmin. Si tratta di un file contenente tutti i dati necessari per creare un nuovo sistema virtuale. Di solito si tratta di un archivio tar o un dump del filesystem dell’intero sistema operativo virtuale. Quando viene creato un sistema virtuale, l’immagine viene utilizzata per popolare il fi lesystem iniziale del sistema operativo virtuale. Ho scaricato un paio di istanze per KVM: una per CentOS 5.4 e una per Ubuntu 10.10. Le dimensioni delle immagini sono variabili, da circa 200 MB fino a 1 GB. Sul sito di Cloudmin ne sono elencate 68, anche se questo numero va diviso per tre perché la maggior parte delle immagini è disponibile in tre varianti: una con il solo sistema operativo di base, una con installato Virtualmin GPL e una terza con Virtualmin Pro. Ogni immagine è specifica per un sistema di virtualizzazione.
Ho contato circa 36 immagini per Xen (o Citrix/Xen),sei per OpenVZ, 11 per KVM e sei per Solaris Zones. Se non c’è un’immagine adatta alle vostre esigenze è possibile crearsene una con gli strumenti forniti da Cloudmin, a partire dal dump di un disco (o di una partizione primaria) di un sistema esistente. Infine ho dovuto creare un’istanza di macchina.Come potete vedere dalla schermata di creazione di un nuovo sistema nella pagina precedente, occorre fornire parecchie informazioni di confi gurazione, tra cui il nome dell’host, un gruppo (ne parlerò in seguito),il percorso del file con l’immagine di sistema, la password per il login SSH (o una coppia di chiavi), la quantità di memoria e di spazio su disco da allocare all’istanza,l’indirizzo IP e così via.
Una volta riempito il modulo ci sono voluti circa 70 secondi per creare l’istanza e installare su di essa l’immagine di sistema. A quanto mi è dato di sapere non è possibile dire “creami dieci istanza come questa” come, per esempio, si può fare con l’interfaccia utente di Amazon Web Services. È però possibile clonare un’istanza esistente con solo un paio di click del mouse. Al clone viene assegnato un nuovo nome e un nuovo indirizzo IP, ma per il resto è una copia dell’originale, con lo stesso fi lesystem, la stessa password, gli stessi limiti sulle risorse e lo stesso proprietario. Quindi, tanto per provare, ho creato un clone. La mia prima macchina virtuale usava un semplice login basato su password, ma per la seconda ho deciso di fare le cose per bene e ho creato una coppia di chiavi da usare con SSH. Dal prompt di comandi sul sistema master ho lanciato il comando ssh-keygen per generare la coppia di chiavi che poi ho importato in Cloudmin. Copiando la chiave pubblica all’interno dell’istanza sono poi stato in grado di collegarmi senza usare nessuna password dalla macchina su cui avevo copiato la chiave privata.
Sistema vuoto
È anche possibile creare un’istanza che è solo un sistema vuoto, cioè che non ha nessun sistema operativo installato sul suo disco virtuale. Quando si sceglie questa opzione
occorre specificare un’immagine di CD o un lettore fisico di CD-ROM collegato al sistema che verrà usato per installare il sistema operativo. Una volta completata l’installazione
il sistema può essere trattato come qualsiasi altra macchina virtuale di Cloudmin. In linea
di principio è possibile installare sistemi operativi diversi da Linux,ma Cloudmin ha una limitata capacita di gestire sistemi del genere. Diamo un’occhiata ad alcune delle funzionalità disponibili per la gestione dei sistemi appena creati. È possibile cambiare la password di login; è possibile clonarli oppure creare un’immagine di sistema che può in seguito essere usata per creare nuove istanze;è possibile installarci sopra Virtualmin o Webmin; è possibile spostarli su un diverso sistema ospitante (o almeno è possibile se avete più di un sistema ospitante!); è possibile riportarli al loro stato iniziale; è possibile aprire un terminale di root (con il browser); è possibile lanciare comandi arbitrari e trasferire fi le in entrambe le direzioni, anche se l’interfaccia per queste operazioni è piuttosto elementare. Infi ne è ovviamente possibile metterli in pausa,arrestarli, riavviarli o cancellarli completamente. Finora ho portato a termine metà della mia missione: ho creato tre istanze KVM (una CentOS, una Ubuntu e un clone) e posso eseguire il login su di esse come root. Per completare il resto della missione, cioè creare e gestire istanze di macchine EC2, ci vuole un po’ di copia e incolla per importare le credenziali del mio account AWS in Cloudmin, in modo che sia in grado di accedere all’API di AWS a mio nome.Devo ammetterlo, non me la cavo bene con le chiavi.Però ho diligentemente importato l’ID del mio account AWS,l’ID della chiave di accesso, la chiave segreta di accesso,il certificato X509 e la chiave privata X509. Non è complicato come potrebbe sembrare, dato che la maggior parte delle informazioni è riportata nel menu Security Credentials della console AWS. Come probabilmente saprete se avete già creato un’istanza di macchina Linux su EC2, l’unica forma di autenticazione SSH disponibile è per mezzo di una coppia di chiavi: l’autenticazione con password non è supportata. Occorre quindi creare una coppia di chiavi in EC2, scaricarle sul nodo master di Cloudmin e poi da qui importarle in Cloudmin.Ho avuto qualche difficoltà con il modulo Create EC2 Instance di Cloudmin. Come per molte cose nella vita, ci sono più maniere per sbagliare che per fare giusto. Quello che ha reso l’operazione particolarmente difficoltosa è il fatto che, ogni volta che tornavo al modulo per riprovare, dovevo ricominciare da zero a riempire i campi. Questo sembra essere vero in generale per Cloudmin: se la cava bene a verifi care la correttezza dei dati inseriti, ma assolutamente male quando si tratta di ripopolare un modulo per consentire all’utente un secondo tentativo. In un modo o nell’altro alla fine ce l’ho fatta. La creazione dell’istanza EC2 e la verifi ca del suo stato via SSH hanno richiesto circa due minuti. Ovviamente creare la seconda è stato molto più facile. È anche possibile importare in Cloudmin istanze EC2 esistenti, ma non ci ho provato. Cosi alla fine mi sono ritrovato con sei macchine sotto il controllo di Cloudmin: il nodo master, due istanza ospitate in locale e un clone di una di esse e un paio di istanze EC2. Le potete vedere nella schermata Cloudmin Managed Systems. Missione compiuta! anche uno o due percorsi guidati per aiutare l’utente nelle operazioni più frequenti. Le capacità di gestire operazioni “di massa” è piuttosto limitata: è possibile dare comandi da eseguire su più sistemi, ed è tutto. Data la potenziale eterogeneità dei sistemi sotto il controllo di Cloudmin forse ci si può aspettare solo questo. Ci sono parecchie funzionalità di Cloudmin che non ho esplorato. Tra queste:
Location group: quando viene creata una nuova istanza probabilmente all’utente interessa conoscere la sua collocazione fi sica, anche se magari non gli interessa sapere su quale sistema ospitante sta girando. Un location group è un insieme di sistemi ospitanti che di solito si trovano nella stessa locazione fi sica. Al momento della creazione di un sistema virtuale è possibile sceglierne tra i location group disponibili quello su cui farlo girare. Il nodo che ospiterà il sistema virtuale viene scelto tra i membri del gruppo in base alla disponibilità di memoria libera, di spazio su disco oppure a caso.
Host failover group: un failover group è una collezione di sistemi ospitanti che condividono la memoria di massa usata per i sistemi virtuali e quindi possono agire come backup uno dell’altro se uno di essi smette di funzionare. Questo permette di riavviare automaticamente un sistema virtuale su un altro sistema ospitante con lo stesso disco virtuale o fi lesystem nel caso di guasto hardware a uno dei nodi fi sici che compongono il gruppo.
System alert: Cloudmin è in grado di monitorare i sistemi gestiti e di inviare allarmi se l’utilizzo delle risorse va al di sopra o al di sotto di soglie specifi cate. È possibile impostare allarmi per singoli sistemi, per tutti i sistemi oppure per sistemi di un dato tipo, come OpenVZ o KVM. Le risorse monitorate comprendono l’utilizzo della CPU,della memoria e lo spazio su disco. Quando si verifica un allarme Cloudmin può spedire un messaggio di posta elettronica all’amministratore del nodo master, ai “proprietari” dei sistemi che hanno causato l’allarme oppure a un qualsiasi altro indirizzo specifi cato.
System owner: un system owner (proprietario del sistema) è un account limitato di Cloudmin. Quando viene creata un’istanza è possibile assegnarle un system owner: si tratta di un utente che può eseguire il login su Cloudmin, ma che vedrà solo le macchine che gli sono state assegnate. Un system owner ha accesso root a tutte le sue istanze e può riavviarle e persino cancellarle, ma non può eseguire operazioni sui sistemi ospitanti o cambiare le impostazioni globali di confi gurazione. È anche possibile defi nire degli account plan che limitano l’utilizzo di spazio su disco, CPU, memoria e banda. Si può tenere traccia dell’utilizzo delle risorse per periodi di tempo predefi niti e calcolare quanto addebitare al cliente finale. Queste funzionalità sono di grande utilità per i fornitori di servizi di hosting che addebitano l’utilizzo dei loro sistemi ai clienti e hanno bisogno di tenere sotto controllo i loro sistemi.
