|
|||||||||||||||
|
Sono usciti numerosi articoli nella KB di vmware, e dai titoli qualcuno di questi sembrerebbe molto interessante. Mi sono ripromesso di leggerli bene con calma e commentare qua i migliori, in questi giorni sono sovraccarico, causa ultimi lavori preparatori per (speriamo) portare a casa un cliente che ospiteremo su Amazon EC2 Ciao, Luca. OT pauroso, ma magari a qualcuno serve. Ho una rete di soli mac di un cliente, e un mac mini deve diventare il file server per tutti. Mac OS X ha una feature di sicurezza che a seconda delle occasioni, può essere estremamente intelligente oppure dannatamente fastidiosa: se anche la share iniziare è condivisa per un gruppo, ogni nuovo file viene salvato con diritti di modifica solo per il creatore, e tutti gli altri utenti non lo possono modificare. In un gruppo di lavoro ovviamente questo è devastante, in quanto ogni utente dopo aver salvato un file dovrebbe andare a modificarne le proprietà a manina, ma ve lo immaginate un utente medio a fare ciò? Purtroppo questa feature è prerogativa di OS X Server, e con la versione client bisogna ingegnarci. Come? Eseguendo ogni 5 minuti o anche meno con cron un comando del tipo: sudo /bin/chmod -R ug+rw /Path/to/shared/folder/ Questo comando prende i permessi iniziali della cartella condivisa (ovvero quelli che voi avete deciso) e li propaga a tutti i files e sottocartelle presenti nella share. E’ brutto da vedere, ma almeno funziona! PS: per poter far girare lo script con l’utente admin di default, è necessario abilitare l’uso di sudo senza password. Per farlo editate /etc/sudoers e togliete il commento alla riga: Dopo di che eseguite il comando: dove a username sostituite il vostro account. PS2: ovviamente dovrete aver creato un gruppo locale da attribuire nelle ACL. Dentro a questo gruppo metterete gli utenti che debbono accedere a quella cartella. Vi segnalo questo ottimo articolo di Scott Lowe, che descrive passo passo come realizzare un sistema automatizzato di installazione e configurazione di ESX. Buona lettura. Spesso nei miei articoli, quando dedicati al mondo delle piccole aziende, avete trovato recensioni e opinioni di svariati storage iscsi. Ultimamente molti produttori si sono accorti delle potenzialita’ di questo settore e stanno proponendo prodotti interessanti. Tutti questi apparati pero’ hanno un limite che li accomuna tutti: la flessibilita’. Chi permette di installare solo 4 dischi, chi non consente di creare piu’ di tot LUN, chi ancora non ha filtri e permessi su chi puo’ connettersi. Esiste allora qualcosa che possa andare oltre, senza spendere follie? Si’, decisamente. Il nome della soluzione e’ Openfiler. Di cosa si tratta: una distribuzione linux progettata specificatamente per realizzare sistemi di storage. semplicita’ di installazione e utilizzo, flessibilita’ e scalabilita’ assolute, la possibilita’ di utilizzare qualsiasi hardware sia riconosciuto da un kernel linux, questi sono i punti di forza di questa soluzione. Senza contare la possibilita’ con le versioni a pagamento di realizzare sistemi SAN ridondati e altre spettacolari funzioni. Per il progetto VI-in-a-box, ho creato in vmware una nuova virtual machine con 512 mb di ram e un disco da 5 Gb (ne aggiungeremo un secondo da 50 gb per lo storage successivamente), insieme a due schede di rete che colleghero’ alle reti iscsi e di gestione. L’installazione e’ molto semplice: avviando il sistema col cd disponibile nel sito web (vi consiglio la versione a 64 bit a meno che non possediate un processore di qualche anno fa che non la supporti) arriviamo dopo poche schermate al partizionamento del disco. Essendo un sistema demo non ho creato configurazioni particolari, quindi ho accettato il layout proposto e ho proseguito. Ho configurato le schede di rete e l’hostname come descritto nello schema del precedente articolo, e infine la password di root. La schermata successiva e’ subito quella dell’installazione, che si concludera’ in pochi minuti:
Prima del riavvio del sistema, ho aggiunto un secondo hard disk da 50 Gb dove configureremo lo storage iscsi. Al riavvio la schermata di Openfiler ci invita a collegarsi all’indirizzo https://172.50.50.13:446. Su questa pagina troviamo l’interfaccia di gestione di Openfiler, dalla quale da ora in poi potremo gestire tutto il sistema.
non fatevi confondere dalla password di root impostata durante il setup; per accedere alla gestione del sistema dovete usare l’utente “openfiler” con password “password”. La prima cosa che dobbiamo fare e’ impostare il disco da 50 Gb per poterlo utilizzare:
Ci rechiamo quindi nella sezione indicata dalla schermata precedente e lo creiamo in pochi semplici passaggi. Selezioniamo il disco /dev/sdb/ e scorrendo la schermata usiamo il menu in fondo per creare una partizione di tipo physical volume usando tutto lo spazio disponibile. Creiamo quindi un nuovo Volume Group che risiedera’ sul disco appena configurato. Apriamo il tab Volumes e selezioniamo Volume Groups. Gli diamo un nome e gli assegniamo il disco /dev/sdb/. E’ tempo di creare un volume. Per farlo usiamo il comando “add volume” sulla destra. Ci viene chiesto su quale volume group crearlo (ne abbiamo uno solo), scorrendo impostiamo un nome al volume, la dimensione che dovra’ avere, ma soprattutto che vorremo usare il formato iscsi.
Dobbiamo adesso abilitare il target iscsi. Selezioniamo il tab “services” e abilitiamo “iSCSI target server”. Torniamo nella sezione Volumes e selezioniamo sulla destra iscsi targets. Nel menu “target configuration” troveremo il valore iqn impostato da openfiler. Possiamo decidere di tenercelo o di personalizzarlo. Passiamo al tab “LUN mapping”. I settaggi di default write-thru e block-io vanno bene, quindi semplicemente selezioniamo il comando Map. Spostiamoci nel menu Network ACL: qua diremo quali macchine potranno connettersi a questa LUN. Dovremo innanzitutto configurare le Local Networks seguendo il link presentato. Qua, per una estrema sicurezza, potremo creare un singolo record per ognuno dei server esx, impostando l’indirizzo ip del port group iscsi (172.60.60.11 e 172.60.60.12 se ci riferiamo al mio schema ricordato prima) e immettendo una subnet a 32 bit (255.255.255.255). In questo modo tornando nelle acl potremo far si che solo i due server esx possano collegarsi alla lun, garantendo una elevata sicurezza del sistema. Per completezza (e per i vari San Tommaso la fuori…) ecco la schermata di una macchina esx col target iscsi correttamente connesso:
Ecco fatto! Spero che durante la navigazione nelle schermate vi sarete accorti di quante opzioni siano disponibili in Openfiler. Fatene buon uso! Questo è quello che promette un nuovo portale messo a disposizione di tutti da parte di EMC2. ECN (EMC Community Network) raccoglie articoli, tutorial, video, posts, un forum di discussione, per apprendere ulteriormente come intergrare i prodotti storage EMC con vmware. Vedremo se la promessa apertura consentirà anche di vedere articoli riguardanti la concorrenza. Da un cliente stiamo approntando un sistema composto da uno storage iscsi condiviso attraverso openfiler, e due nodi ESXi 4.0 free. Come ho fatto spesso con 3.5, volevamo aggiungere la virtual machine che era in esecuzione sul nodo A all’inventario del nodo B, in modo da averla sempre pronta all’avvio. Un primo dubbio ci era venuto dall’icona del file vmx, non visibile col classico logo vmware dal nodo B ma come un file generico. A virtual machine spenta abbiamo potuto aggiungere la macchina all’inventario di B prima di avviarla, salvo poi ad un successivo riavvio ritrovare la macchina indicata come Unkonwn (Invalid). Da una ricerca, parrebbe che con ESXi 4.0 sono state cambiate le impostazioni dei lock sulle virtual machines, tali percui qualsiasi operazione su una macchina in esecuzione sono esclusive del nodo che la sta eseguendo, compresa l’aggiunta all’inventario. Morale: aggiungete la virtual machine al nodo secondario solo quando serve. Update: con l’aggiornamento U1, le macchine non sono piu’ in stato unknown, ma risultano sempre in lock se avviate dall’altro nodo. Amazon ha rilasciato una nuova tipologia di istanza, denominata High Memory Extra Large (m2.xlarge) con le seguenti specifiche: Se vi servisse quindi una macchina media su EC2, eccola qua. Se siete interessati a lavorare nel vCloud Team di VMWare, Duncan Epping ha postato sul suo blog questo articolo, in cui elenca le posizioni attualmente aperte. Se pensate che una delle figure richieste potrebbe corrispondere a voi, scrivetegli. Abbiamo già parlato in altre occasioni dell’utilità di utilizzare le istanze EBS su Amazon Web Services. Che fare però se stiamo finendo lo spazio disco e rischiamo di bloccare il server ospitato? Se potete permettervi un piccolo tempo di down della virtual machine (pochi minuti), ecco come fare. Prendiamo ad esempio un’istanza Ubuntu 9.10 Karmic EBS boot instance (ami-6743ae0e). Se controlliamo lo spazio disco otterremo: $ df -h / Eseguiremo tutti questi comandi su una seconda macchina, uguale a quella produttiva, che accenderemo appositamente. Scegliamo innanzitutto una nuova dimensione del disco: instanceid=<YOURINSTANCEID> Otteniamo anche informazioni circa l’id del root EBS volume e della availability zone: oldvolumeid=$(ec2-describe-instances $instanceid | Arrestate (non terminate!) l’istanza: ec2-stop-instances $instanceid Staccate il volume originario dall’istanza: while ! ec2-detach-volume $oldvolumeid; do sleep 1; done Create una snapshot del volume originario: snapshotid=$(ec2-create-snapshot $oldvolumeid | cut -f2) Create un nuovo volume a partire dalla snapshot, specificando in questo punto la nuova dimensione, ovviamente maggiore dell’originale: newvolumeid=$(ec2-create-volume \ Attaccate il nuovo volume all’istanza: ec2-attach-volume \ Avviate l’istanza e scoprite qual’è il suo nuovo IP pubblico o l’hostname. Se state utilizzando elastic IP, assegnatelo a questa nuova istanza: ec2-start-instances $instanceid Collegatevi all’istanza via ssh e ridimensionate il file system di root per utilizzare il nuovo spazio messo a disposizione: # ext3 root file system (è il più comune che troverete nelle varie immagini disponibili) # XFS root file system: Verificate che dopo tutto questo lavoraccio la partizione sia veramente diventata da 20 GB: $ df -h / Cancellate a questo punto il vecchio volume EBS e la snapshot se non vi servono più. Magari tenetevi per qualche tempo almeno la snapshot, non si sa mai: ec2-delete-volume $oldvolumeid Dal momento che avete connesso a mano questo volume all’istanza, non verrà cancellato automaticamente in fase di cancellazione dell’istanza stessa, a meno che non modifichiate questo comportamento. Mi è arrivata ieri una mail da Trilead, in cui viene annunciata la versione 2.0 del loro software di backup. Tra le novità presenti, assolutamente da notare il supporto per vcenter. Non saremo quindi più costretti a linkare ogni singolo esx autonomamente rischiando di perdere i backup quando una macchina viene spostata tramite vmotion. Questo era forse il più grande limite del prodotto, che lo rendeva perfetto per i piccoli ambienti creati con la versione free di ESXi ma non per strutture più grosse. Adesso si può tranquillamente proporre il prodotto per piccoli clienti, stando tranquilli che il giorno in cui vorranno mettersi un vcenter non dovranno buttare il software di backup per prenderne uno nuovo. Attendiamo adesso la possibilità di installarlo come servizio, anche se qua con la possibilità di schedulare le stringhe di comandi col task scheduler di Windows il problema non è insormontabile. |
|
||||||||||||||
|
Copyright © 2010 vuemuer.pmiservice.biz - All Rights Reserved 7 guests, 0 members Max visitors today: 7 at 12:43 am CET This month: 23 at 03-05-2010 12:35 am CET This year: 41 at 01-27-2010 07:21 am CET All time: 41 at 01-27-2010 07:21 am CET |
|||||||||||||||
))
