Home > Informatica, Linux, Server > Cambio hardware di uno SME server

Cambio hardware di uno SME server

Non sempre tutto il male viene per nuocere… e in questo caso mai proverbio fu più veritiero. Ma cominciamo dall’inizio…

La mattina del 29 Aprile un provider italiano (nello specifico Aruba) ha avuto un problema per cui il loro datacenter è stato “spento”. La loro nota riporta che “la mattina del 29 aprile, alle 04:30 un corto circuito negli armadi batterie degli Ups ha causato un principio di incendio, rilevato dal sistema di protezione che ha attivato quello di estinzione. La combustione della plastica delle batterie ha generato fumo che ha saturato i locali. Il sistema ha interpretato il fumo come una prosecuzione dell’incendio, interrompendo la fornitura di energia elettrica.
In termini pratici il loro datacenter e tutti i siti e servizi/sistemi che forniscono sono andati offline. Ciò si è trasformato nell’impossibilità di visitare siti internet da loro “ospitati” e il non ricevere posta per tutto il tempo che i loro server erano kaputt.

Tale evento (il male di cui sopra) ha provocato in alcuni individui la consapevolezza che forse quel fesso di pseudoconsulente che da anni va predicando che un’azienda seria deve avere un suo server con la sua posta e il suo dominio presso la propria sede aziendale con una linea ridondata e tutte le sicurezze del caso non ha tutti i torti. E così mi cominciano a piovere addosso diverse telefonate… 🙂

Caso volle che, in tale frangente, una segretaria intrapendente e speranzosa di risolvere il suo urgente problema ha pensato che probabilmente sarebbe stata cosa buona e giusta togliere di netto la corrente al server aziendale che non riceveva più le email (prelevandole dai server  Aruba). Al server tale fatto non è piaciuto molto, infatti per dispetto ha fatto saltare uno dei due HD interni e tale guasto non permetteva nemmeno il funzionamento del server in quanto a un successivo avvio il BIOS rimaneva inchiodato cercando di capire quale periferica era collegata a uno dei sui canali IDE senza che tale periferica rispondesse adeguatamente…

Dopo i controlli del caso si decide quindi che bisogna sostituire tutto il server per paura che ci possa essere anche qualcos’altro di guasto (incredibile!!! tale decisione è stata presa dalla direzione senza che alcuno gli fornisse una benchè minima base logica per tale sostituzione…). Mi sono quindi trovato a dover cambiare l’hardware di uno SME server.
Operazione semplice e indolore pensavo io… di solito in questi casi risolvevo con un “backup su desktop” e un successivo “restore da desktop” tramite l’apposita procedura dal server-manager di SME ma… era da un po che non la facevo!!! Mi accorgo quindi (ovviamente DOPO aver aspettato 4 ore per il completamento del backup sul desktop) che dalla versione 7.4 dello SME server il restore da desktop è stato eliminato… 😯
Mi sono quindi ritrovato a utilizzare una procedura per me nuova (mai fatto prima in questo modo) ma che si è rivelata molto più performante e semplice di quanto pensassi…

Il sistema è illustrato nel dettaglio in questa pagina; in pratica si mettono due server (vecchio e nuovo) nella stessa rete e con pochi e semplici comandi da console si fa il “trasporto” di dati e configurazioni da un server all’altro in un colpo solo. Riporto qui i passaggi effettuati (che sono gli stessi descritti nella pagina linkata prima… hai visto mai dovesse andare offline il sito di SME e mi serve la procedura… :D).

Intanto bisogna controllare ceh i due server siano aggiornati e quindi uno “yum update” su entrambi e d’obbligo. Devono inoltre essere raggiugibili via SSH dalla rete impostando opportunamente dal server -manager il sistema di accesso. Una volta effettuato ciò bisogna installare sul server nuovo il contrib che permette la gestione della procedura con i comando

yum install --enablerepo=smecontribs smeserver-affa

Una volta installato e riavviato il server tramite i classici “signal-event post-upgrade & reboot” bisogna configurare il contrib digitando da console

db affa set AffaGlobalDisable yes
db affa set prodserv job
db affa setprop prodserv remoteHostName IPdelServerVecchio
db affa setprop prodserv RPMCheck yes
affa --make-cronjobs

Quindi bisogna generare una chiave DSA e inviarla al server di produzione (quello “vecchio” diciamo) tramite il comando

affa --send-key prodserv

Ci verrà quindi richiesta la password del server di produzione e una volta inserita ci verrà confermato l’invio tramite un apposito messaggio a video.
Cominceremo quindi la copia dei file delle impostazioni del server tramite il comando

affa --run prodserv

Alla fine di questa procedura c’è da controllare un file (/var/affa/prodserv/rpms-missing.txt); se tale file è vuoto significa che possiamo andare avanti con la procedura, diversamente verranno indicati in questo file i pacchetti che sono installati nel server di produzione ma che non sono presenti in quello “nuovo”. In quest’ultimo caso occorrerà aggiornare/installare i pacchetti pe rpoter procedere.
Ipotizzando che il file sia vuoto (e quindi nessun problema) bisogna finalizzare la procedura. Da questo momento in poi inizia il downtime del server.
Intanto bisogna fermare alcuni servizi sul server di produzione; quindi sul server vecchio bisogna inserire le seguenti righe

SVC='qpsmtpd sqpsmtpd crond imap pop3 imaps pop3s ftp httpd-e-smith atalk smb qmail'
for s in $SVC; do service $s stop; done

Quindi sul server nuovo daremo di nuovo

affa --run prodserv

Tale comando sincronizzerà solo i dati che sono stati eventualmente modificati dall’ultima volta che abbiamo lanciato questo stesso comando poco prima.
Terminato ciò bisognerà spegnere il vecchio server con “poweroff” e finalizzare la procedura sul nuovo server con successivo riavvio tramite i comandi

affa --rise --all prodserv
reboot

Dopo il riavvio il nuovo server sarà “pronto all’uso” come se fosse il vecchio. Qui termina il downtime del server

L’ultima operazione da eseguire è la pulizia dei residue di Affa, pulizia che si effettua con i comandi

/bin/rm -rf /var/affa
yum remove smeserver-affa perl-Filesys-DiskFree perl-Compress-Bzip2
rm -f /etc/cron.d/affa-status /etc/cron.d/affa
rm -rf /home/e-smith/db/affa /home/e-smith/db/affa-report
rm -rf /var/log/affa

questo eliminerà Affa e tutti gli archivi/file/sarcazzi che la procedura ha creato con ovvio risparmi di spazio sull’HD.

Scrivevo sopra che la creazione del backup su desktop ha richiesto circa 4 ore… la procedura suindicata ha richiesto meno di 10 minuti (9Gb il file creato in 4 ore precedentemente)… un bel risparmio di tempo eh… 🙂

E’ d’obbligo un “grazie Stefano” per avermi suggerito l’utilizzo di questo sistema… un bel risparmio di tempo… e si sà… il tempo è denaro!!! 😀

  1. rob
    25 ottobre 2011 a 11:20 | #1

    ciao volevo chiederti se questa procedura è applicabile nella situazione in cui il server nuvo abbia un hd piu capiente.

  2. Fumetto
    25 ottobre 2011 a 21:36 | #2

    Decisamente si, nel caso illustrato sopra sono pasasto da 320Gb a 500Gb.

  3. davide
    21 novembre 2011 a 14:50 | #3

    ciao, guida utilissima e per questo ti chiedo: ho un server con sme che fa da dns e ftp devo x forza prepararne uno di backup su un pc normalissimo in modo che se succede un disaster attacco il backup e riparto a bomba. qst nuova macchina di bck ha un hardware diverso, non ci sono problemi o controindicazioni ??? grazie mille!!!

  4. Fumetto
    22 novembre 2011 a 3:59 | #4

    Nessuna controindicazione. Questa guida è però valida se il “vecchio” server è ancora funzionante, se non dovesse esserlo il restore può essere effettuato solo se è stata implementata una procedura di backup su un hardware esterno al server (NAS, DAT…)

  5. davide
    22 novembre 2011 a 9:09 | #5

    ultimissima domanda…i contribs devo reinstallarli manualmente o lui riesce a farmi un ghost perfetto della macchina???? grazie mille ancora

  6. Fumetto
    22 novembre 2011 a 13:27 | #6

    Le impostazioni dei contribs vengono salvate nel db che viene “backuppato”, i contribs veri e propri bisogna reinstallarli ma dopo uno “yum install quelcheè” sono già perfettamente funzinanti e configurati.

  7. davide
    29 novembre 2011 a 9:16 | #7

    ciao ancora, ho ancora un paio di dom ande prima di cimentarmi….gli ip sulle schede di rete come li riassegna????? poi…con affa ottengo la solita cosa che reinstallare su un nuovo HW uno sme server e fare ripristino da backup????? o il risultato di affa è migliore??? grazie tanto ancora

  8. Fumetto
    29 novembre 2011 a 22:00 | #8

    Per gli IP non ti so dire, nel mio caso avevo un server con una sola scheda quindi tutto è andato a posto “da solo”… nel caso basta riconfigurare da console e riassegnare le schede.
    Affa fà più o meno quello che farebbe un ripristina da backup precedente; devi solo stare attento a che non ci siano contribs o qualcos’altro installato o con dati inseriti in directory “esterne” a quelli che sono i percorsi standard… per esempio affa mi pare non faccia il bacup della directory /opt
    Maggiori informazioni sul forum italiano 😉

  1. Nessun trackback ancora...