Anche se l’offerta di VM a livello server, sotto Mac OS X, è praticamente nulla, è possibile usare prodotti come Parallels o VMWare Fusion con buoni risultati come alternativa “dei poveri”. Tuttavia, non esiste un modo ufficiale per migrare da Parallels a Fusion se l’OS non è Windows ma è possibile farlo “a mano”, seguendo queste istruzioni.
Come molti di voi sapranno, l’avvio in single user mode, sotto Mac OS X, non richiede l’inserimento di alcuna password. In aggiunta all’uso della password sul firmware, possiamo fare in modo che venga chiesta la password di root anche in single usare mode modificando il file /etc/ttys. Da:
console "/System/Library/CoreServices/loginwindow.app/Contents/MacOS/loginwindow" \ vt100 on secure onoption="/usr/libexec/getty std.9600"
a:
console "/System/Library/CoreServices/loginwindow.app/Contents/MacOS/loginwindow" \ vt100 on onoption="/usr/libexec/getty std.9600"
Occhio agli “a–capo”!
Viste le mie recenti vicissitudini con gli aggiornamenti di Apple, per non parlare dell’ultima disavventura con QuickTime 7.2 che ha coinvolto anche me, costringendomi all’ennesimo archive & install, ecco un articolo che spiega come mitigare i rischi in un ambiente dove viene usato l’Apple Software Update Server.
Come dicevo ieri, High Scalability è una miniera di informazioni. In questo articolo viene discusso lo sharding per scalare in orizzontale applicazioni che si appoggiano ad un database SQL – praticamente il 90%, direi – per la gestione dei dati.
L’idea è quasi banale. Di solito il DBMS gira su una sola macchina e solo gli strati più alti dell’architettura, come l’application server e il server web vengono scalati in orizzontale; se si vogliono aumentare le prestazioni del DBMS si aggiorna l’hardware. Lo sharding cerca di risolvere questo problema segregando i dati in blocchi (o se preferite, in schegge, traducendo direttamente shard). Ogni blocco è indipendente e quindi diventa possibile rendere più lineare la scalabilità del sistema, aggiungendo hardware in modo progressivo solo quando richiesto.
Ho qualche dubbio sul fatto che i dati debbano essere necessariamente denormalizzati: credo dipenda molto dallo schema; anzi, direi che l’evitare la denormalizzazione dovrebbe essere uno dei criteri per “scheggiare” la base dati. Ovviamente, i vari sistemi DBMS sono anch’essi interpellati da problematiche e soluzioni come queste: è il loro settore, no?
Questo suggerimento da Mac OS X Hints mi ha “ispirato”a proporre una versione alternativa. Per smontare i dischi esterni FireWire:
system_profiler SPFireWireDataType \ | grep BSD | awk '{ print $3 }' \ | while read i; do diskutil unmountDisk $i; done
e per rimontarli:
system_profiler SPFireWireDataType \ | grep BSD | awk '{ print $3 }' \ | while read i; do diskutil mountDisk $i; done
A volte preferisco awk a sed ;-)
Presso un cliente, dopo aver acquistato un MacBook Pro, si è presentata la necessità di migrare i dati dal suo portatile sulla nuova macchina. Il vecchio computer era un Sony Vaio (un “portatile” da 7kg) con Windows XP, svariati eseguibili semi–custom senza installer e 27GB di dati, dislocati su due partizioni.
Non essendo un esperto di Windows e volendo limitare al massimo le operazioni manuali e avendo deciso in anticipo di non usare BootCamp ma Parallels, ho pensato di provare ad usare Transporter, sempre di Parallels. Questa utility promette di creare un macchina virtuale pronta all’uso a partire da:
Ci sono diversi modi di effettuare questa migrazione. La prima possibilità prevede il lancio sulla macchina sorgente di un agent che dialogo via rete con il Transporter che gira sulla macchina di destinazione. Dopo un paio di tentativi falliti (l’agent rispondeva ma al Transporter risultava impegnato in un’altra operazione) sono passato alla seconda opzione. Ho lanciato Transporter sulla macchina d’origine in modalità avanzata, salvando il disco immagine sul file server dato che il disco non aveva spazio sufficiente. Dopo circa 4 ore l’immagine era pronta.
Dopo aver copiato l’immagine su Mac, la prima cosa fare è riconfigurare i device: il floppy è stato disabilitato, il suono è rimappato su quello del Mac, idem per la rete e CD/DVD. Fatto questo ho acceso la VM e qui ho fatto il primo (e unico, per la verità!) grosso errore. La VM parte regolarmente ma Windows (credo) rileva le modifiche all’hardware e, una volta arrivati alla finestra di login, non risponde per un paio di minuti. Non sperando di aver azzeccato tutto al primo tentativo, ho spento la VM e mi sono imbarcato nell’importazione della VM in un’altra VM. Risultato: 4 ore perse.
Comunque, una volta superato questo scoglio c’è stato un altro problema da risolvere: la licenza di Windows. Appena dopo aver fatto il login, viene chiesto di attivare XP ma senza successo, dato che è già attivato, infine viene forzato il logout. Dopo svariate telefonate mi viene opportunamente suggerito di chiamare il supporto di Microsoft. Mezz’ora dopo la telefonata si è conclusa così:
“–Quindi mi state dicendo che sono a piedi? –Beh, sì”.
In realtà la soluzione è banale: bisogna avviare Windows in modalità provvisoria, che si attiva premendo ripetutamente F8 al boot, avendo cura di configurare la tastiera sotto Mac in modo che richieda del tasto FN. Una volta entrato come Administrator ho lanciato il ripristino dall’installer di Windows per poi poter attivare la nuova licenza – non so se l’installer originale del Vaio avrebbe avuto lo stesso risultato. Una volta finita l’installazione, ho disinstallato il software in bundle con il Vaio che non aveva più senso conservare.
Questo è più o meno quanto. Riassumendo:
Tutto sommato mi sembra una procedura affidabile e, cosa forse più importante, senza stress.
Altre info su Transporter.
Alcuni possibili usi delle opzioni avanzate messe a disposizione da ZFS:
Vengono impostati in modo selettivo alcuni parametri, a seconda della directory. L’etc non sarà eseguibile e verranno create delle snapshot in automatico; per la var verranno usate delle quote, in modo da impedire problemi con l’accumulo dei log, accoppiate con le prenotazioni (reservation) in modo che ci sia sempre almeno 1G di spazio libero.
Non vedo l’ora di provarlo sotto Mac OS X…
Uno dei problemi abbastanza spinosi legati all’amministrazione dei server è il backup selettivo delle configurazioni “importanti”. In altre parole: come scegliere, fra gli innumerevoli file disseminati qua e la, quelli critici.
Tralasciamo per ora soluzioni più radicali a questo problema e concentriamoci solo su Mac OS X Server, vorremmo poter copiare, in un modo che sia anche automatizzabile tutte le configurazioni riportate in Server Admin. Per farlo basta usare la versione da terminale di questa applicazione: serveradmin.
In breve, basteranno questi due comandi:
serveradmin settings all > serverconf.backup
e:
serveradmin settings < serverconf.backup
Il primo salva tutte le configurazioni e il secondo le ricarica.
Se lo desideriamo, possiamo essere più selettivi e scegliere di backuppare solo alcuni dei servizi, elencabili con:
serveradmin list
oppure possiamo sfruttare il fatto che ogni singolo valore di configurazione sta su una singola riga che inizia sempre per “nomeservizio:” per filtrarlo tramite grep.
Una volta decisa qual’è il metodo che pensiamo sia il più adatto, è banale configurare programmare un backup regolare con cron/periodic.
Come forse alcuni ricorderanno, quando Steve Jobs presentò l’iPhone qualche mese fa, accennò al fatto che l’iPhone avrebbe supportato il protocollo IMAP anche in modalità “push”. In pratica questo vuol dire che i nuovi messaggi di posta in arrivo sul server IMAP vengono inviati al client senza che quest’ultimo debba esplicitamente chiederli, a intervalli regolari o meno.
Questo tipo funzionalità viene implementata tramite il comando IDLE, che fa parte di LEMONADE, un insieme di opzioni per permettere un uso migliore dei server IMAP da parte di dispositivi mobili. Questo comando fa in modo che il server informi il client dell’arrivo di nuovi messaggi non appena arrivano.
Con lo ZFS adesso è anche possibile delegare dei compiti amministrativi ad utenti “normali”. Ad esempio, dopo aver creato un pool, possiamo dire che il gruppo “staff” può creare e montare dei filesytem in quel pool.