Newsgroup: it.comp.os.linux.sys
Titolo: DRBD 0.7 su Debian Lenny

Ciao a tutti!
Sto testando su una macchina virtuale i casini che mi comporterebbe
l'aggiornamento Debian etch => lenny...
Attualmente i casini sono TANTI.
A cominciare da DRBD 0.7 che non si lascia compilare su lenny.
Tramite module-assistant ho sempre compilato e installato senza
problemi il modulo, ma ora, con lenny, non va piu'.
Ricevo sempre questo errore:
make -C /lib/modules/2.6.26-2-686/build SUBDIRS=/usr/src/modules/drbd/
drbd  modules
make[1]: Entering directory `/usr/src/linux-headers-2.6.26-2-686'
scripts/Makefile.build:46: *** CFLAGS was changed in "/usr/src/modules/
drbd/drbd/Makefile". Fix it to use EXTRA_CFLAGS.  Schluss.
make[1]: *** [_module_/usr/src/modules/drbd/drbd] Fehler 2
make[1]: Leaving directory `/usr/src/linux-headers-2.6.26-2-686'
make: *** [kbuild] Fehler 2
Purtroppo, da una ricerca in google, vedo che non sono l'unico ad aver
avuto questo problema.
In compenso non ho trovato nessuno con una soluzione...
Magari qualcuno di voi e' riuscito nell'impresa?
Grazie
Luca Bertoncello
(
luca...@lucabert.de
)

 Magari qualcuno di voi e' riuscito nell'impresa?
Se leggessi le ML di drbd scopriresti che il branch 0.7 non è più 
manutenuto da tempo e che consigliano *vivamente* di passare al 0.8
Ed è anche il consiglio che ti do io.

 'EXTRA_CFLAGS', dovrai correggerlo a mano mi sa'.
Che l'ho anche fatto, eh!
Pero' non funziona lo stesso... Il risultato e' questo:
    Calling toplevel makefile of kernel source tree, which I believe
is in
    KDIR=/lib/modules/2.6.26-2-686/build
test -f ../scripts/adjust_drbd_config_h.sh && \
         KDIR=/lib/modules/2.6.26-2-686/build /bin/bash ../scripts/
adjust_drbd_config_h.sh
  Using unmodified drbd_config.h
make -C /lib/modules/2.6.26-2-686/build SUBDIRS=/usr/src/modules/drbd/
drbd  modules
make[1]: Entering directory `/usr/src/linux-headers-2.6.26-2-686'
  CC [M]  /usr/src/modules/drbd/drbd/drbd_sizeof_sanity_check.o
  CC [M]  /usr/src/modules/drbd/drbd/drbd_buildtag.o
  CC [M]  /usr/src/modules/drbd/drbd/drbd_bitmap.o
In file included from /usr/src/modules/drbd/drbd/drbd_bitmap.c:32:
/usr/src/modules/drbd/drbd/drbd_int.h:752: warning: ‘request_queue_t’
is deprecated
/usr/src/modules/drbd/drbd/drbd_int.h:1041: warning: ‘request_queue_t’
is deprecated
In file included from /usr/src/modules/drbd/drbd/drbd_int.h:1149,
                 from /usr/src/modules/drbd/drbd/drbd_bitmap.c:32:
/usr/src/modules/drbd/drbd/drbd_compat_wrappers.h: In function
‘drbd_bio_IO_error’:
/usr/src/modules/drbd/drbd/drbd_compat_wrappers.h:381: error: too many
arguments to function ‘bio_endio’
/usr/src/modules/drbd/drbd/drbd_compat_wrappers.h: In function
‘drbd_bio_endio’:
/usr/src/modules/drbd/drbd/drbd_compat_wrappers.h:386: error: too many
arguments to function ‘bio_endio’
/usr/src/modules/drbd/drbd/drbd_compat_wrappers.h: In function
‘drbd_ee_prepare_write’:
/usr/src/modules/drbd/drbd/drbd_compat_wrappers.h:514: warning:
assignment from incompatible pointer type
/usr/src/modules/drbd/drbd/drbd_compat_wrappers.h: In function
‘drbd_ee_prepare_read’:
/usr/src/modules/drbd/drbd/drbd_compat_wrappers.h:522: warning:
assignment from incompatible pointer type
/usr/src/modules/drbd/drbd/drbd_compat_wrappers.h: In function
‘drbd_req_prepare_write’:
/usr/src/modules/drbd/drbd/drbd_compat_wrappers.h:533: warning:
assignment from incompatible pointer type
/usr/src/modules/drbd/drbd/drbd_compat_wrappers.h: In function
‘drbd_req_prepare_read’:
/usr/src/modules/drbd/drbd/drbd_compat_wrappers.h:550: warning:
assignment from incompatible pointer type
/usr/src/modules/drbd/drbd/drbd_compat_wrappers.h: At top level:
/usr/src/modules/drbd/drbd/drbd_compat_wrappers.h:585: warning:
‘request_queue_t’ is deprecated
/usr/src/modules/drbd/drbd/drbd_compat_wrappers.h: In function
‘drbd_plug_device’:
/usr/src/modules/drbd/drbd/drbd_compat_wrappers.h:605: warning:
‘request_queue_t’ is deprecated
make[2]: *** [/usr/src/modules/drbd/drbd/drbd_bitmap.o] Fehler 1
make[1]: *** [_module_/usr/src/modules/drbd/drbd] Fehler 2
make[1]: Leaving directory `/usr/src/linux-headers-2.6.26-2-686'
make: *** [kbuild] Fehler 2
Altre idee?
Grazie
Luca Bertoncello
(
luca...@lucabert.de
)


E l'ho anche letto, ma per motivi vari, mi piacerebbe restare sulla
0.7.
In ogni caso, se proprio tutto fa fiasco, hai consigli per migrare
senza problemi da 0.7 a 0.8?
Grazie
Luca Bertoncello
(
luca...@lucabert.de
)

 --------CUT -------------
Scusate, forse mi sono perso qualcosa, ma onestamente non capisco il
perché di dover fare tutto 'sto casino.
In lenny sono già presenti nei repository ufficiali tutti i pacchetti
necessari relativi alle utility ed ai moduli kernel per le versione
0.8 di drbd e ti assicurano che funzionano senza nessun problema, ho
un paio di cluster in produzione da diverso tempo con queste versioni
e non ho riscontrato alcun problema.
Ti installi la tua lenny di base e poi un bel apt-cache search drbd
seguito da un bel apt-get install drbd-$QUELLO_CHE_TI_SERVE e vivi
sereno!

 sereno!
Come ho detto, non parto da una macchina vuota, ma da servers gia' in
produzione da due anni.
Ho fatto dei tests, ma ancora non sono riuscito a far parlare DRBD0.7
(di etch) con DRBD0.8 (di lenny).
Puoi dirmi come fare?
Ciao
Luca Bertoncello
(
luca...@lucabert.de
)

 Puoi dirmi come fare?
La risposta è dentro di te, però è sbagliata.
Vai su google, digita "drbd upgrade 0.7 0.8 step by step"
e premi "mi sento fortunato".

 e premi "mi sento fortunato".
Si, questo l'avevo gia' visto...
Pero' non mi aiuta, in quanto mi dice chiaramente che devo
assolutamente avere entrambi i nodi spenti per un certo periodo di
tempo (quello che mi serve per convertire tutte le partizioni DRDB
dalla 0.7 alla 0.8).
Ma ho fatto un Cluster proprio per non dover interrompere il servizio.
Oltretutto, in qualunque momento lo faccia, ci saranno sicuramente
clienti che si lamentano.


 Altre idee?
Rimani con etch.

 
From here to eternity...

 From here to eternity...
http://www.youtube.com/watch?v=Q83FKwJId2I
(a rivederlo fa quasi tenerezza..)
-- 
Professional System & Network Sarcazzer
http://bofhskull.wordpress.com/


Allora Io di solito quando devo fare queste operazioni (giusto giusto
la settimana scorsa ho aggiornato un cluster heartbeat+drbd da SLES9 a
SLES11 e ne ho un'altro questa settimana) mi muovo in questo modo:
- Premessa importantissima!!: I servers coinvolti nella migrazione
hanno il disco su cui è installato il sistema operativo mirrorato in
raid 1 HW.
1 - Sposto tutti i servizi su un nodo (che chiameremo nodo2)
2 - Shutdown del nodo "passivo" (che chiameremo nodo1) e "sfilo" uno
dei dischi in mirror.
3 - Installo il nuovo sistema operativo da zero e mi configuro tutto
sul nodo1.
4 - Sfilo il disco con il sistema aggiornato, re-infilo quello vecchio
e faccio ripartire il nodo1.
5 - Sposto tutti i servizi da nodo2 a nodo1 ed effettuo per il nodo2
tutte le operazioni di cui ai punti 2 e 3.
A questo punto mi trovo con entrami i server che dispongono della
possibilità di essere avviati con entrambe le versioni del sistema
operativo.
6 - Ora faccio una migrazione manuale e cioè manualmente tiro su i
servizi sul nodo2 che avrò avviato con il sistema nuovo e mi sposto i
vari virtual ip a mano se necessario.
7 - Tiro su il nodo1 con il sistema nuovo e faccio sincronizzare il
drbd.
8 - Provo un paio di switch del cluster per vedere se li effettua
correttamente testando (se possibile) le varie condizioni di fault.
9 - Tengo il tutto così in prova per qualche giorno, se tutto funziona
correttamente un nodo alla volta faccio sincronizzare i dischi di
mirror che avevo sfilato.
In caso incontrassi invece insormontabili problemi ho sempre la
possibilità di tornare indietro nel tempo di un reboot sfruttando i
dischi di mirror che avevo sfilato e che contengono una copia del
"vecchio" S.O.
Se non ha i dischi in mirror sei in un vicolo cieco! O trovi una terza
macchina da usare come appoggio durante la migrazione oppure ti
attacchi.
Personalmente non tenterei la strada dell'aggiornamento forzato da una
versione all'altra in quanto rischi di creare disservizi più lunghi di
quelli necessari a re-installare la macchina da capo.
Ciao Ciao

 hai o tiri giu' il cluster intanto che fai l'aggiornamento.
E non dimenticarti di verificare i backup prima di tutto cio`.
E/oppure sincronizzi un terzo nodo che lasci accessibile in sola
lettura (se possibile) mentre aggiorni gli altri due (che hai staccato
da quello) e in questo modo ti eviti anche di dover controllare che i
backup abbiano funzionato a dovere prima di cominciare.
Andrea

 quelli necessari a re-installare la macchina da capo.
Il problema e' che i due Servers sono dal Provider e io NON ho accesso
fisico alla sala macchine dove sono quei Servers...
Oltretutto, il problema non e' vedere se funziona dopo
l'aggiornamento, quello l'ho gia' visto sui vari tests con le VMs.
Il problema e' proprio che, facendo l'aggiornamento non riesco piu' a
usare DRBD 0.7 e mi trovo forzato ad usare DRBD 0.8.
Solo che non riesco a pensare ad un modo per tenere un nodo con DRBD
0.7 e l'altro DRBD 0.8.
Se riuscissi, potrei spostare tutti i servizi su un nodo e aggiornare
l'altro.
Poi, spostare a mano tutti i servizi sulla seconda macchina (che pero'
usa DRBD 0.8) e aggiornare l'altra.
Il problema e' che, pero', da quello che capisco non mi e' possibile
mantenere sincronizzate le partizioni DRBD se su una macchina c'e' la
0.7 e sull'altra la 0.8...
Idee?
Luca Bertoncello
(
luca...@lucabert.de
)

 Idee?
Passare a problemi risolubili e lasciare quelli irresolubili ad altri,
oppure provare la via della terza macchina (se si puo` procurare).
Comunque la soluzione piu` lineare sembrerebbe essere quella di
avvisare con congruo anticipo gli utenti della sospensione del
servizio, fermarlo e poi aggiornare.
Andrea


A questo punto fallo lo stesso lo switch manuale sincronizzando anche
il contenuto delle partizioni manualmente. Considera che anche con il
cluster funzionante una micro interruzione di servizio l'avrai
comunque. Non per farmi gli affari tuoi, ma cosa c'è su 'sta
partizione in drbd? Effettua un elevato numero di scritture in
continuazione? Non puoi mettere il tutto in Read Only per il tempo
strettamente necessario a sincronizzare le partizioni a mano (intendo
copiando i files) e far ripartire tutto sul nuovo sistema?

 problemi in caso di guasto HARDWARE
Mmmh, no. Per evitare i guasti hardware la soluzione più efficace è 
ridondare l'hardware nella macchina nelle parti più sensibili (RAID, doppia 
alimentazione). La cosa interessante di un cluster è poter anche fare 
manutenzione controllata senza perdere servizio.
O almeno io personalmente faccio sempre così.
-- 
Vide

 (a rivederlo fa quasi tenerezza..)
Lacrimuccia :')
-- 
Vide

 copiando i files) e far ripartire tutto sul nuovo sistema?
Ci sono tre partizioni:
La prima contiene le pagine Web (e quelle non cambiano cosi'
rapidamente), i Logs di Apache e la configurazione e i Logs di Exim/
Mailin (e quelli cambiano gia' un po' piu' rapidamente)
La seconda la configurazione e i Logs di Exim/Mailout e di
SpamAssassin e ClamAV
La terza il DB... E qui son dolori, direi...
Idee?
Grazie
Luca Bertoncello
(
luca...@lucabert.de
)

 Idee?
Chiedere sulla mailing list di drbd.
Assumere coloro che sviluppano e vendono drbd (linbit mi sembra e
stanno in Austria) e con poche migliaia di EUR (probabilmente 8-9000),
vengono li` e forse ti risolvono il problema (o magari se gli dai
accesso alla macchina da remoto forse te lo fanno anche per 6-7000).
Andrea

 Idee?
Non so che database usi, però ad esempio mssql (e penso anche altri)
permettono di utilizzare una tecnica che si chiama log shipping.
In pratica, fai il backup del db, e lo ripristini sul nuovo nodo tenendo il
db in read-only.
A questo punto il db di partenza lo fermi, fai il backup del transaction log
(operazione molto più breve) e ripristini sul nuodo nodo il transaction log
e si riattiva il database in modalità lettura-scrittura. Con script già
pronti e tutto l'operazione può richiedere qualche minuto al max.
Il backup del log può essere fatto più volte ed ogni volta vengono
backuppate solo le modifiche dall'ultimo log-backup in poi.
Viene anche utilizzato per tenere una copia del db in stand-by aggiornata
(da usare in caso di crash del server principale, qualora non ci si possa
permettere di avere un cluster) ogni x minuti.

 La terza il DB... E qui son dolori, direi...
Direi che è il meno impegnativo perchè, a meno che tu non usi oracle su 
OCFS, sia mysql che postgres non sono clusterizzabili in master-master.
Quindi rsync è altrettanto adatto.

 Quindi rsync è altrettanto adatto.
Se i dati ti servono con alcuni minuti di differenza.
Ma se fai una configurazione master-slave in cui lo slave viene
interrogato realmente (e non è quindi un mero backup), rsync
non va affatto bene.
E poi che fai, ogni volta sullo slave fai drop e create del database
con rispettiva importazione?
-- 
Non tocca a noi dominare tutte le maree del mondo,
il nostro compito è di fare il possibile per la
salvezza degli anni nei quali viviamo,
sradicando il male dai campi che conosciamo.

 Quindi rsync è altrettanto adatto.
Ma anche no. Posto che ogni RDBMS fa storia a se, ognuno prevede uno o piu` 
sistemi di replica (e.g. per PostgreSQL ci sono pgpool e slony-I)
Enrico

 piu` sistemi di replica (e.g. per PostgreSQL ci sono pgpool e slony-I)
Se hai sistemi di replica, aggiornare un server non è un problema.

 rispettiva importazione?
EH ?

 Ma in questo caso non usi drbd
Hai detto di sincronizzare tramite rsync i due server.
rsync non è in tempo reale, quindi devi copiare brutalmente
i file oppure fare un dump e sincronizzare quello sul secondo
server.
Il secondo server poi deve essere istruito per leggere i nuovi dati,
o tramite un reload, o tramite un restore del dump.
In emtrambi i casi, la sincornizzazione non è in real-time ed è
parecchio invasiva.
Non hai un cluster, hai un failover in questo caso.


 parecchio invasiva.
Non pretende di esserlo, visto che devi aggiornare DRBD.
Era la base del ragionamento fatto prima.
Stavo sottolineando che DRBD *comunque* con i DB, a meno di situazioni 
particolari, non funziona in multi-master quindi il problema di tirarne 
giù uno non sussite.
Se hai un cluster, hai come minimo anche il failover.