Discussion:
Problemi con iscsi e bonding in squeeze
(too old to reply)
Domenico Rotella
2011-03-25 09:33:42 UTC
Permalink
Ciao a tutti,
ho un paio di problemi con squeeze, premesso che ho già configurato un paio
di server come quello che mi sta dando problemi, unica differenza la distro,
le alte volte volte ho usato Lenny...
Questo il punto:
creo una bond (una scheda di rete "virtuale" che sfrutta due schede reali
"accoppiate" per maggiori performance) con due schede rete, carico il modulo
per il kernel con modprobe, restarto il servizio di rete e la nuova
interfaccia è su, riavvio ed il modulo non viene più caricato... con
modprobe nome-modulo se non ricordo male al riavvio ricaricava il modulo
stesso.
Altro problema con iscsi, configuro il target, quindi "il server", il
servizio non parte perchè manca il modulo iscsi_trtg, peccato che non esista
sul server, nonostante abbia installato i sorgenti del kernel ed anche
iscsitarget-source.
Suggerimenti ?
Grazie in anticipo.
Domenico.
--
-------
"Eliminato l'impossibile ciò che resta per quanto improbabile è la verità".
Conan Doyle.
Nicola Manca
2011-03-25 11:39:52 UTC
Permalink
per caricare un modulo in automatico devi inserirne il nome in
/etc/modules, forse è un metodo deprecato ma funziona.

per quanto riguarda il modulo ho visto che esiste un vecchio bug, il
modulo veniva creato ma non copiato nella cartella del kernel, nel caso
dovrebbe trovarsi ancora nella cartella dei sorgenti, se è così trovalo
copialo e poi lancia

depmod -a

proprio fatto alla buona...

ciao!
Post by Domenico Rotella
Ciao a tutti,
ho un paio di problemi con squeeze, premesso che ho già configurato un
paio di server come quello che mi sta dando problemi, unica differenza
la distro, le alte volte volte ho usato Lenny...
creo una bond (una scheda di rete "virtuale" che sfrutta due schede
reali "accoppiate" per maggiori performance) con due schede rete, carico
il modulo per il kernel con modprobe, restarto il servizio di rete e la
nuova interfaccia è su, riavvio ed il modulo non viene più caricato...
con modprobe nome-modulo se non ricordo male al riavvio ricaricava il
modulo stesso.
Altro problema con iscsi, configuro il target, quindi "il server", il
servizio non parte perchè manca il modulo iscsi_trtg, peccato che non
esista sul server, nonostante abbia installato i sorgenti del kernel ed
anche iscsitarget-source.
Suggerimenti ?
Grazie in anticipo.
Domenico.
--
-------
"Eliminato l'impossibile ciò che resta per quanto improbabile è la verità".
Conan Doyle.
--
Per REVOCARE l'iscrizione alla lista, inviare un email a
debian-italian-***@lists.debian.org con oggetto "unsubscribe". Per
problemi inviare un email in INGLESE a ***@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@gmail.com
Alessandro Baggi
2011-03-25 11:48:07 UTC
Permalink
Post by Nicola Manca
per caricare un modulo in automatico devi inserirne il nome in
/etc/modules, forse è un metodo deprecato ma funziona.
per quanto riguarda il modulo ho visto che esiste un vecchio bug, il
modulo veniva creato ma non copiato nella cartella del kernel, nel
caso dovrebbe trovarsi ancora nella cartella dei sorgenti, se è così
trovalo copialo e poi lancia
depmod -a
proprio fatto alla buona...
ciao!
Post by Domenico Rotella
Ciao a tutti,
ho un paio di problemi con squeeze, premesso che ho già configurato un
paio di server come quello che mi sta dando problemi, unica differenza
la distro, le alte volte volte ho usato Lenny...
creo una bond (una scheda di rete "virtuale" che sfrutta due schede
reali "accoppiate" per maggiori performance) con due schede rete, carico
il modulo per il kernel con modprobe, restarto il servizio di rete e la
nuova interfaccia è su, riavvio ed il modulo non viene più caricato...
con modprobe nome-modulo se non ricordo male al riavvio ricaricava il
modulo stesso.
Altro problema con iscsi, configuro il target, quindi "il server", il
servizio non parte perchè manca il modulo iscsi_trtg, peccato che non
esista sul server, nonostante abbia installato i sorgenti del kernel ed
anche iscsitarget-source.
Suggerimenti ?
Grazie in anticipo.
Domenico.
--
-------
"Eliminato l'impossibile ciò che resta per quanto improbabile è la verità".
Conan Doyle.
Ciao Domenico. Stavo studiando anche io iscsitarget + open-iscsi con
debian 6.0. Se ho capito bene manca il modulo iscsi_trgt su debian,
questo perche il modulo deve essere compilato. In rete si trovano molte
howto, di solito se hai una procedura per la compilazione manuale dei
moduli seguila, altrimenti puoi usare module-assistant e debhelper.

# apt-get install iscsitarget-source debhelper module-assistant
# m-a a-i iscsitarget

il modulo viene compilato automaticamente. Dopo di che viene creato il
.deb che puoi installare anche su tutti gli altri target.
Spero di esserti stato utile.
Saluti
--
Per REVOCARE l'iscrizione alla lista, inviare un email a
debian-italian-***@lists.debian.org con oggetto "unsubscribe". Per
problemi inviare un email in INGLESE a ***@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@gmail.com
dea
2011-03-25 12:57:30 UTC
Permalink
Post by Alessandro Baggi
Ciao Domenico. Stavo studiando anche io iscsitarget + open-iscsi con
debian 6.0. Se ho capito bene manca il modulo iscsi_trgt su debian,
questo perche il modulo deve essere compilato. In rete si trovano
molte howto, di solito se hai una procedura per la compilazione
manuale dei moduli seguila, altrimenti puoi usare module-assistant e
debhelper.
# apt-get install iscsitarget-source debhelper module-assistant
# m-a a-i iscsitarget
il modulo viene compilato automaticamente. Dopo di che viene creato
il .deb che puoi installare anche su tutti gli altri target. Spero
di esserti stato utile. Saluti
Si, confermo, è così. Lo uso su due SAN (Debian 6.0) e funziona benissimo.

Luca
Domenico Rotella
2011-03-25 13:23:47 UTC
Permalink
Post by dea
Post by Alessandro Baggi
Ciao Domenico. Stavo studiando anche io iscsitarget + open-iscsi con
debian 6.0. Se ho capito bene manca il modulo iscsi_trgt su debian,
questo perche il modulo deve essere compilato. In rete si trovano
molte howto, di solito se hai una procedura per la compilazione
manuale dei moduli seguila, altrimenti puoi usare module-assistant e
debhelper.
# apt-get install iscsitarget-source debhelper module-assistant
# m-a a-i iscsitarget
il modulo viene compilato automaticamente. Dopo di che viene creato
il .deb che puoi installare anche su tutti gli altri target. Spero
di esserti stato utile. Saluti
Si, confermo, è così. Lo uso su due SAN (Debian 6.0) e funziona benissimo.
Luca
--
Per REVOCARE l'iscrizione alla lista, inviare un email a
with a subject of "unsubscribe". Trouble? Contact
Dopo aver scritto in lista ho cercato ancora un pò in /usr/share/doc ed ho
visto quanto da voi suggerito, provato e funziona.
La cosa che credo non abbia molto senso è questo "passo indietro", mi
spiego:
il mese scorso ho fatto un server identico con lenny e non ho avuto alcun
problema, nè a creare il bonding, nè con iscsi, esisteva un pacchetto con i
sorgenti, bastava installarlo così, "apt-get install
iscsitarget-modules-`uname
-r`"
non mi è chiaro questo passo indietro.
Comunque risolto, grazie per le dritte.
Domenico.
--
-------
"Eliminato l'impossibile ciò che resta per quanto improbabile è la verità".
Conan Doyle.
Alessandro Baggi
2011-03-25 13:53:41 UTC
Permalink
Post by dea
Post by Alessandro Baggi
Ciao Domenico. Stavo studiando anche io iscsitarget + open-iscsi con
debian 6.0. Se ho capito bene manca il modulo iscsi_trgt su debian,
questo perche il modulo deve essere compilato. In rete si trovano
molte howto, di solito se hai una procedura per la compilazione
manuale dei moduli seguila, altrimenti puoi usare module-assistant e
debhelper.
# apt-get install iscsitarget-source debhelper module-assistant
# m-a a-i iscsitarget
il modulo viene compilato automaticamente. Dopo di che viene creato
il .deb che puoi installare anche su tutti gli altri target. Spero
di esserti stato utile. Saluti
Si, confermo, è così. Lo uso su due SAN (Debian 6.0) e funziona benissimo.
Luca
--
Per REVOCARE l'iscrizione alla lista, inviare un email a
"unsubscribe". Per
with a subject of "unsubscribe". Trouble? Contact
Dopo aver scritto in lista ho cercato ancora un pò in /usr/share/doc
ed ho visto quanto da voi suggerito, provato e funziona.
La cosa che credo non abbia molto senso è questo "passo indietro", mi
il mese scorso ho fatto un server identico con lenny e non ho avuto
alcun problema, nè a creare il bonding, nè con iscsi, esisteva un
pacchetto con i sorgenti, bastava installarlo così, "apt-get install
iscsitarget-modules-`uname -r`"
non mi è chiaro questo passo indietro.
Comunque risolto, grazie per le dritte.
Domenico.
--
-------
"Eliminato l'impossibile ciò che resta per quanto improbabile è la verità".
Conan Doyle.
Per curiosità, siccome non dispongo di risorse per poter provare una SAN
su HOST reali, sono costretto a provarlo su macchine virtuali, dove le
performance sono abbastanza ridotte. A livello di configurazione e
funzionalità sono abbastanza soddisfatto, ma a livello di performance
non posso dire altrettanto. Come vi trovate con le vostre SAN a livello
di performance? Inoltre, se posso, da quante macchine è composta la
vostra SAN e che carico devono sopportare?
--
Per REVOCARE l'iscrizione alla lista, inviare un email a
debian-italian-***@lists.debian.org con oggetto "unsubscribe". Per
problemi inviare un email in INGLESE a ***@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@gmail.com
Domenico Rotella
2011-03-25 14:19:06 UTC
Permalink
Il giorno 25 marzo 2011 14:53, Alessandro Baggi
Post by Alessandro Baggi
Post by Alessandro Baggi
Per curiosità, siccome non dispongo di risorse per poter provare una SAN
su HOST reali, sono costretto a provarlo su macchine virtuali, dove le
performance sono abbastanza ridotte. A livello di configurazione e
funzionalità sono abbastanza soddisfatto, ma a livello di performance non
posso dire altrettanto. Come vi trovate con le vostre SAN a livello di
performance? Inoltre, se posso, da quante macchine è composta la vostra SAN
e che carico devono sopportare?
Personalmente ho una situazione un pò complessa, per cui la soddisfazione
varia in base alla configurazione, mi spiego:
2 server in drbd per il datastore delle macchina virtuali, con bonding su
rete a 1Gb e link riservato, nel senso uno switch solo per loro, raid5
hardware, pienamente soddisfatto, trasferisce ottimamente...
un altro server mi esporta dello spazio disco per le macchine virtuali,
anche qui raid 5 ma software, su hardware datato, bonding 2 schede a 100Mb,
qui le performance sono un pò scarse, scrive a 30-40Mb poi ogni tanto "ha
dei colli di bottiglia" però non mi serve che sia veloce,
quest'ultimo per cui ho scritto è un vecchio bakstor della tanderg data che
ho recuperato ed installato linux, ha molto spazio per gli hard disk ma in
generale è in linea con le aspettative dell'hardware, sposta dati a circa
30Mb, mi servirà come datastore per il server di backup bacula per cui anche
qui la velocità non è fondamentale.
Concludendo, direi che le SAN con linux vanno in generale molto bene, a
patto di isolare le reti quando possibile e comunque in linea con
l'hardware....
Diciamo che ho tentato di separare un pò tutto,
2 server esx di cui non uso datastore locali se non per macchine di test
datastore per esx separato su 2 server in drbd
un datastore solo per un reparto aziendale in cui conserviamo documentazione
tecnica
un server per dello spazio disco "lento"
un altro per bacula
un altro ancora per il datastore di bacula
Ho messo in piedi questa configurazione in modo che se un server "muore" io
fermo tutto....

Spero di essere stato esauriente... :)

Domenico.
--
-------
"Eliminato l'impossibile ciò che resta per quanto improbabile è la verità".
Conan Doyle.
Alessandro Baggi
2011-03-25 15:12:34 UTC
Permalink
Post by Domenico Rotella
Il giorno 25 marzo 2011 14:53, Alessandro Baggi
Per curiosità, siccome non dispongo di risorse per poter provare
una SAN su HOST reali, sono costretto a provarlo su macchine
virtuali, dove le performance sono abbastanza ridotte. A livello
di configurazione e funzionalità sono abbastanza soddisfatto, ma a
livello di performance non posso dire altrettanto. Come vi trovate
con le vostre SAN a livello di performance? Inoltre, se posso, da
quante macchine è composta la vostra SAN e che carico devono
sopportare?
Personalmente ho una situazione un pò complessa, per cui la
2 server in drbd per il datastore delle macchina virtuali, con bonding
su rete a 1Gb e link riservato, nel senso uno switch solo per loro,
raid5 hardware, pienamente soddisfatto, trasferisce ottimamente...
un altro server mi esporta dello spazio disco per le macchine
virtuali, anche qui raid 5 ma software, su hardware datato, bonding 2
schede a 100Mb, qui le performance sono un pò scarse, scrive a 30-40Mb
poi ogni tanto "ha dei colli di bottiglia" però non mi serve che sia
veloce,
quest'ultimo per cui ho scritto è un vecchio bakstor della tanderg
data che ho recuperato ed installato linux, ha molto spazio per gli
hard disk ma in generale è in linea con le aspettative dell'hardware,
sposta dati a circa 30Mb, mi servirà come datastore per il server di
backup bacula per cui anche qui la velocità non è fondamentale.
Concludendo, direi che le SAN con linux vanno in generale molto bene,
a patto di isolare le reti quando possibile e comunque in linea con
l'hardware....
Diciamo che ho tentato di separare un pò tutto,
2 server esx di cui non uso datastore locali se non per macchine di test
datastore per esx separato su 2 server in drbd
un datastore solo per un reparto aziendale in cui conserviamo
documentazione tecnica
un server per dello spazio disco "lento"
un altro per bacula
un altro ancora per il datastore di bacula
Ho messo in piedi questa configurazione in modo che se un server
"muore" io fermo tutto....
Spero di essere stato esauriente... :)
Domenico.
--
-------
"Eliminato l'impossibile ciò che resta per quanto improbabile è la verità".
Conan Doyle.
Grazie Domenico. Ho ancora qualche altra domanda al riguardo. Come ho
gia detto la mia SAN è tutta virtuale per scopi di studio e prove, ed è
composta da 4 target e un initiator. Ho provato a lanciare un hdparm -tT
sull'initiator, ma il risultato è deludente. Ovvio che le prestazioni su
macchine virtuali sono molto ridotte, le interfacce sono virtuali, (nel
mio caso senza bonding), gli hdd anche virtuali. Ho provato a lanciare
anche un hdparm su uno dei target, e il risultato è decisamente
migliore. Dato che le prestazioni tra un singolo host e una SAN
dovrebbero essere diverse, suppongo che con 4 target (reali e non
virtuali) dovrebbe andare abbastanza bene, i risultati che mi vengono
proposti da hdparm (su initiator) corrispondono quasi ad 1/4 delle
prestazioni della singola macchina virtuale (pensandoci bene sembra
tutto normale perche le risorse vengono divisi per 4 su un unico host
per 4 vm), ma tralasciando questo, penso che al minimo la velocita
dovrebbe raddoppiare, per cui non posso prendere in considerazione
questi valori.
Volevo chiederti se potevi darmi dei dati veritieri e non fittizzi come
i miei.

L'altra domanda è al riguardo dei raid software. Come detto ho 4 target,
ognuno in una vm, alla quale ho legato 4 hdd virtuali ad ognuna. Dato
che l'obiettivo sarebbe quello di avere una grande quantita di dati ad
alta velocita, su uno spazio vasto, ti volevo chiedere, data la tua
esperienza è preferibile impostare un raid (software o hardware
indipendentemente dalle prestazioni) prima su ogni singolo target, e poi
uno sull'initiator che magari riprende tutti gli altri dev condivisi,
oppure gestire il raid software direttamente dall'initiator? Suppongo la
prima ma un confronto puo aiutare a trovare altre vie.

Ulteriormente, supponendo di voler fornire HA all'initiator della SAN, e
supponendo di avere i target con raid hw, e supponendo di creare un
ulteriore raid sugli initiator (raid5), creando il primo raid sul primo
initiator, dopo averlo creato dovrebbe calcolare la parita per il
failover. Creando invece il raid sul secondo initiator (sempre raid5),
ricalcola la parita e crea problema con il primo initiator? oppure
fornendo un --assume-clean funziona a dovere? oppure è meglio creare un
lvm al posto del raid?

Spero di non essere andato fuori strada.
--
Per REVOCARE l'iscrizione alla lista, inviare un email a
debian-italian-***@lists.debian.org con oggetto "unsubscribe". Per
problemi inviare un email in INGLESE a ***@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@gmail.com
Domenico Rotella
2011-03-25 15:53:17 UTC
Permalink
Il giorno 25 marzo 2011 16:12, Alessandro Baggi
Grazie Domenico. Ho ancora qualche altra domanda al riguardo. Come ho gia
detto la mia SAN è tutta virtuale per scopi di studio e prove, ed è composta
da 4 target e un initiator. Ho provato a lanciare un hdparm -tT
sull'initiator, ma il risultato è deludente. Ovvio che le prestazioni su
macchine virtuali sono molto ridotte, le interfacce sono virtuali, (nel mio
caso senza bonding), gli hdd anche virtuali. Ho provato a lanciare anche un
hdparm su uno dei target, e il risultato è decisamente migliore. Dato che le
prestazioni tra un singolo host e una SAN dovrebbero essere diverse,
suppongo che con 4 target (reali e non virtuali) dovrebbe andare abbastanza
bene, i risultati che mi vengono proposti da hdparm (su initiator)
corrispondono quasi ad 1/4 delle prestazioni della singola macchina virtuale
(pensandoci bene sembra tutto normale perche le risorse vengono divisi per 4
su un unico host per 4 vm), ma tralasciando questo, penso che al minimo la
velocita dovrebbe raddoppiare, per cui non posso prendere in considerazione
questi valori.
Volevo chiederti se potevi darmi dei dati veritieri e non fittizzi come i
miei.
Premesso che in calce ti copio i result di un mio server reale, credo sia
difficile fare una stima ed ottenere dati veritieri nella tua
configurazione.
Mi sembra di capire che tu abbia tutto sulla stessa macchina, questo vuol
dire:
sistema operativo
qualcosa tipo vm-server
le macchine virtuali
i dischi virtuali condivisi
un unico link virtuale. che unisce tutto il sistema....
L'optimum sarebbe poter dividere tutto, io come ti dicevo ho l'esx su una
macchina, il datastore su un altra, dove le macchine sono in drbd, ma questo
è solo per sicurezza, non aumenta la velocità, ed ho tutte reti reali
diverse con uno switch, quindi:
1 - rete lan
2 - rete san per collegare le macchine virtuali all'esx
3 - rete drbd per collegare gli host replicati
poi ok la wan e la dmz ma non sono influenti....
tutti i link sono in rete Gb
questo è hdparm su un sistema raid5 software su un sistema non troppo
performante
Timing cached reads: 1436 MB in 2.00 seconds = 717.41 MB/sec
Timing buffered disk reads: 660 MB in 3.02 seconds = 218.22 MB/sec

questo su un server con un raid5 hardware
Timing cached reads: 1436 MB in 2.00 seconds = 7240.80 MB/sec
Timing buffered disk reads: 660 MB in 3.02 seconds = 171.80 MB/sec
L'altra domanda è al riguardo dei raid software. Come detto ho 4 target,
ognuno in una vm, alla quale ho legato 4 hdd virtuali ad ognuna. Dato che
l'obiettivo sarebbe quello di avere una grande quantita di dati ad alta
velocita, su uno spazio vasto, ti volevo chiedere, data la tua esperienza è
preferibile impostare un raid (software o hardware indipendentemente dalle
prestazioni) prima su ogni singolo target, e poi uno sull'initiator che
magari riprende tutti gli altri dev condivisi, oppure gestire il raid
software direttamente dall'initiator? Suppongo la prima ma un confronto puo
aiutare a trovare altre vie.
Fammi capire, vuoi creare un raid con dello spazio disco importato via iscsi
??
Sinceramente è una cosa che non ho mai fatto, ma credo che non abbia molto
senso.... difficile da gestire, se si guasta un pezzo ? cosa si degrada ?
Quale disco in quale raid ?
Se vuoi avere ottime performance l'unica strada è un unico archivio
esportato via iscsi che colleghi in Gb all'initiator, poi dipende anche se
trasferisci tanti piccoli file o grandi...
Ulteriormente, supponendo di voler fornire HA all'initiator della SAN, e
supponendo di avere i target con raid hw, e supponendo di creare un
ulteriore raid sugli initiator (raid5), creando il primo raid sul primo
initiator, dopo averlo creato dovrebbe calcolare la parita per il failover.
Creando invece il raid sul secondo initiator (sempre raid5), ricalcola la
parita e crea problema con il primo initiator? oppure fornendo un
--assume-clean funziona a dovere? oppure è meglio creare un lvm al posto del
raid?
Come sopra, non ho mai sentito una cosa del genere ma sul mio sistema non la
farei, se ti può servire come consiglio...
Domenico.
--
-------
"Eliminato l'impossibile ciò che resta per quanto improbabile è la verità".
Conan Doyle.
Domenico Rotella
2011-03-25 15:57:45 UTC
Permalink
Il giorno 25 marzo 2011 16:53, Domenico Rotella
<***@gmail.com>ha scritto:

Correzione di hdparm del server con raid hw (errore di copia/incolla.... ;)
questo su un server con un raid5 hardware
Timing cached reads: 14434 MB in 1.99 seconds = 7240.88 MB/sec
Timing buffered disk reads: 516 MB in 3.01 seconds = 171.80 MB/sec
Il giorno 25 marzo 2011 16:12, Alessandro Baggi <
Post by Alessandro Baggi
Post by Alessandro Baggi
Grazie Domenico. Ho ancora qualche altra domanda al riguardo. Come ho
gia detto la mia SAN è tutta virtuale per scopi di studio e prove, ed è
composta da 4 target e un initiator. Ho provato a lanciare un hdparm -tT
sull'initiator, ma il risultato è deludente. Ovvio che le prestazioni su
macchine virtuali sono molto ridotte, le interfacce sono virtuali, (nel mio
caso senza bonding), gli hdd anche virtuali. Ho provato a lanciare anche un
hdparm su uno dei target, e il risultato è decisamente migliore. Dato che le
prestazioni tra un singolo host e una SAN dovrebbero essere diverse,
suppongo che con 4 target (reali e non virtuali) dovrebbe andare abbastanza
bene, i risultati che mi vengono proposti da hdparm (su initiator)
corrispondono quasi ad 1/4 delle prestazioni della singola macchina virtuale
(pensandoci bene sembra tutto normale perche le risorse vengono divisi per 4
su un unico host per 4 vm), ma tralasciando questo, penso che al minimo la
velocita dovrebbe raddoppiare, per cui non posso prendere in considerazione
questi valori.
Volevo chiederti se potevi darmi dei dati veritieri e non fittizzi come i
miei.
Premesso che in calce ti copio i result di un mio server reale, credo sia
difficile fare una stima ed ottenere dati veritieri nella tua
configurazione.
Mi sembra di capire che tu abbia tutto sulla stessa macchina, questo vuol
sistema operativo
qualcosa tipo vm-server
le macchine virtuali
i dischi virtuali condivisi
un unico link virtuale. che unisce tutto il sistema....
L'optimum sarebbe poter dividere tutto, io come ti dicevo ho l'esx su una
macchina, il datastore su un altra, dove le macchine sono in drbd, ma questo
è solo per sicurezza, non aumenta la velocità, ed ho tutte reti reali
1 - rete lan
2 - rete san per collegare le macchine virtuali all'esx
3 - rete drbd per collegare gli host replicati
poi ok la wan e la dmz ma non sono influenti....
tutti i link sono in rete Gb
questo è hdparm su un sistema raid5 software su un sistema non troppo
performante
Timing cached reads: 1436 MB in 2.00 seconds = 717.41 MB/sec
Timing buffered disk reads: 660 MB in 3.02 seconds = 218.22 MB/sec
questo su un server con un raid5 hardware
Timing cached reads: 1436 MB in 2.00 seconds = 7240.80 MB/sec
Timing buffered disk reads: 660 MB in 3.02 seconds = 171.80 MB/sec
Post by Alessandro Baggi
L'altra domanda è al riguardo dei raid software. Come detto ho 4 target,
ognuno in una vm, alla quale ho legato 4 hdd virtuali ad ognuna. Dato che
l'obiettivo sarebbe quello di avere una grande quantita di dati ad alta
velocita, su uno spazio vasto, ti volevo chiedere, data la tua esperienza è
preferibile impostare un raid (software o hardware indipendentemente dalle
prestazioni) prima su ogni singolo target, e poi uno sull'initiator che
magari riprende tutti gli altri dev condivisi, oppure gestire il raid
software direttamente dall'initiator? Suppongo la prima ma un confronto puo
aiutare a trovare altre vie.
Fammi capire, vuoi creare un raid con dello spazio disco importato via
iscsi ??
Sinceramente è una cosa che non ho mai fatto, ma credo che non abbia molto
senso.... difficile da gestire, se si guasta un pezzo ? cosa si degrada ?
Quale disco in quale raid ?
Se vuoi avere ottime performance l'unica strada è un unico archivio
esportato via iscsi che colleghi in Gb all'initiator, poi dipende anche se
trasferisci tanti piccoli file o grandi...
Post by Alessandro Baggi
Ulteriormente, supponendo di voler fornire HA all'initiator della SAN, e
supponendo di avere i target con raid hw, e supponendo di creare un
ulteriore raid sugli initiator (raid5), creando il primo raid sul primo
initiator, dopo averlo creato dovrebbe calcolare la parita per il failover.
Creando invece il raid sul secondo initiator (sempre raid5), ricalcola la
parita e crea problema con il primo initiator? oppure fornendo un
--assume-clean funziona a dovere? oppure è meglio creare un lvm al posto del
raid?
Come sopra, non ho mai sentito una cosa del genere ma sul mio sistema non
la farei, se ti può servire come consiglio...
Domenico.
--
-------
"Eliminato l'impossibile ciò che resta per quanto improbabile è la verità".
Conan Doyle.
--
-------
"Eliminato l'impossibile ciò che resta per quanto improbabile è la verità".
Conan Doyle.
Alessandro Baggi
2011-03-25 18:41:22 UTC
Permalink
Post by Domenico Rotella
Il giorno 25 marzo 2011 16:12, Alessandro Baggi
Grazie Domenico. Ho ancora qualche altra domanda al riguardo. Come
ho gia detto la mia SAN è tutta virtuale per scopi di studio e
prove, ed è composta da 4 target e un initiator. Ho provato a
lanciare un hdparm -tT sull'initiator, ma il risultato è
deludente. Ovvio che le prestazioni su macchine virtuali sono
molto ridotte, le interfacce sono virtuali, (nel mio caso senza
bonding), gli hdd anche virtuali. Ho provato a lanciare anche un
hdparm su uno dei target, e il risultato è decisamente migliore.
Dato che le prestazioni tra un singolo host e una SAN dovrebbero
essere diverse, suppongo che con 4 target (reali e non virtuali)
dovrebbe andare abbastanza bene, i risultati che mi vengono
proposti da hdparm (su initiator) corrispondono quasi ad 1/4 delle
prestazioni della singola macchina virtuale (pensandoci bene
sembra tutto normale perche le risorse vengono divisi per 4 su un
unico host per 4 vm), ma tralasciando questo, penso che al minimo
la velocita dovrebbe raddoppiare, per cui non posso prendere in
considerazione questi valori.
Volevo chiederti se potevi darmi dei dati veritieri e non fittizzi
come i miei.
Premesso che in calce ti copio i result di un mio server reale, credo
sia difficile fare una stima ed ottenere dati veritieri nella tua
configurazione.
Mi sembra di capire che tu abbia tutto sulla stessa macchina, questo
sistema operativo
qualcosa tipo vm-server
le macchine virtuali
i dischi virtuali condivisi
un unico link virtuale. che unisce tutto il sistema....
L'optimum sarebbe poter dividere tutto, io come ti dicevo ho l'esx su
una macchina, il datastore su un altra, dove le macchine sono in drbd,
ma questo è solo per sicurezza, non aumenta la velocità, ed ho tutte
1 - rete lan
2 - rete san per collegare le macchine virtuali all'esx
3 - rete drbd per collegare gli host replicati
poi ok la wan e la dmz ma non sono influenti....
tutti i link sono in rete Gb
questo è hdparm su un sistema raid5 software su un sistema non troppo
performante
Timing cached reads: 1436 MB in 2.00 seconds = 717.41 MB/sec
Timing buffered disk reads: 660 MB in 3.02 seconds = 218.22 MB/sec
questo su un server con un raid5 hardware
Timing cached reads: 1436 MB in 2.00 seconds = 7240.80 MB/sec
Timing buffered disk reads: 660 MB in 3.02 seconds = 171.80 MB/sec
L'altra domanda è al riguardo dei raid software. Come detto ho 4
target, ognuno in una vm, alla quale ho legato 4 hdd virtuali ad
ognuna. Dato che l'obiettivo sarebbe quello di avere una grande
quantita di dati ad alta velocita, su uno spazio vasto, ti volevo
chiedere, data la tua esperienza è preferibile impostare un raid
(software o hardware indipendentemente dalle prestazioni) prima su
ogni singolo target, e poi uno sull'initiator che magari riprende
tutti gli altri dev condivisi, oppure gestire il raid software
direttamente dall'initiator? Suppongo la prima ma un confronto puo
aiutare a trovare altre vie.
Fammi capire, vuoi creare un raid con dello spazio disco importato via
iscsi ??
Sinceramente è una cosa che non ho mai fatto, ma credo che non abbia
molto senso.... difficile da gestire, se si guasta un pezzo ? cosa si
degrada ? Quale disco in quale raid ?
Se vuoi avere ottime performance l'unica strada è un unico archivio
esportato via iscsi che colleghi in Gb all'initiator, poi dipende
anche se trasferisci tanti piccoli file o grandi...
Ulteriormente, supponendo di voler fornire HA all'initiator della
SAN, e supponendo di avere i target con raid hw, e supponendo di
creare un ulteriore raid sugli initiator (raid5), creando il primo
raid sul primo initiator, dopo averlo creato dovrebbe calcolare la
parita per il failover. Creando invece il raid sul secondo
initiator (sempre raid5), ricalcola la parita e crea problema con
il primo initiator? oppure fornendo un --assume-clean funziona a
dovere? oppure è meglio creare un lvm al posto del raid?
Come sopra, non ho mai sentito una cosa del genere ma sul mio sistema
non la farei, se ti può servire come consiglio...
Domenico.
--
-------
"Eliminato l'impossibile ciò che resta per quanto improbabile è la verità".
Conan Doyle.
Per quanto riguarda la prima domanda, si è tutto su una unica macchina,
è il mio portatile.

Comincio a fare un po di confusione.
Se dico qualcosa di sbagliato correggimi.
Con una SAN, (tralasciando le schede di rete) abbiamo un initiator e dei
target, in sostanza il target è colui che da i dischi e l'initiator è
quello che lo dovrebbe gestire. L'utilizzo di una SAN è legato alla
velocita con cui i dati vengono trasmessi, e questo non fa forza solo
sulle schede di rete ma anche hdd, processori ecc..., ecco per cui
utilizziamo molteplici macchine per lo scopo.
Penso che gli scopi per cui si usa iscsi possano essere principalmente due:
1) Avere N macchine, ognuna con uno storage per una determinata sezione,
e quindi "aggregarli" su un unico sistema. Ma questa tipologia puo
essere schivata.
2) (questa secondo me è la piu utile) Avere N macchine, ognuna con N
hdd, per creare una unica grande rete che raggiunge dimensioni di
storage molto molto elevate, questo dovrebbe essere uno dei motivi per
cui si dice low cost e con prestazioni abbastanza elevate.

Per la prima ipotesi, diciamo che la possiamo tralasciare, avere N
server storage e aggregarli su una unica macchina, non mi sembra poi
cosi utile, in fondo lo abbiamo gia il server, che fa il lavoro che deve
fare, anzi, se l'initiator fallisce abbiamo un unico punto di
fallimento, se cade l'initiator cade tutta la rete.

iscsi ci permette per cui di dare all'initiator un certo numero di
dischi, sia questo un hdd normale, sia un md, o un lvm.

Prendiamo in considerazione la seconda ipotesi.
Ora la domanda che mi pongo è: e se volessi creare un sistema con uno
storage di dimensioni molto elevate (fantastichiamo petabyte, oppure
3000 TB) per un qualche scopo, come fare per ovviare a questo? Fino ad
ora non ho mai sentito di singole macchine che hanno controller in grado
di fare cio (parliamo sempre di bassi costi, non di mainframe), per ora
penso che la soluzione possa essere un Cluster di hdd, e per le
operazioni servono sempre CPU, RAM etc...e penso che con iscsi si possa
fare molto facilmente, ovvio diventa complesso da gestire ma si possono
creare sempre sistemi di automazione.

Per la questione dei raid, su ogni singola macchina (target), dovremmo
mettere i dischi in raidN per fornire una qualche ridondanza per i dati,
sulla singola macchina, in quanto ora sono le singole macchine a fare da
point of failure oltre che all'initiator. Per cui se si rompe una
macchina, o un hdd, o qualche componente e la macchina diventa inusabile
la rete cade (mi riferisco agli hdd), sempre nel caso di un unico grande
storage. Ma se invece provvediamo a fornire una ridondanza in rete? Per
esempio un raid 1 tra due dev di due diverse macchine (la
sincronizzazione verra tra i due hdd via iscsi e vie rete) Facciamo
conto che drbd non esista, anche se penso che si basi sullo stesso
principio. Bhe penso che se cade la prima abbiamo sempre la seconda,
ovvio che si abbasserebbero le performance fino alla risincronizzazione.

Quello che ho pensato io è: abbiamo 4 target e un initiator. Sui target
abbiamo 12 HDD che configuriamo con un raid5 hardware o software che sia
(tralasciamo i livelli dei raid) per cui vedremo /dev/md0 sui target,
sull'initiator abbiamo invece i dev importati sdb, sdc, sdd e sde. E fin
qui tutto bene. Supponiamo ora di volere un unico gigante archivio per
esempio per lo storage di siti e materiale relativo ai siti, per una
webfarm. Il miglior modo per poter fare cio sarebbe quello di
condividere i raid dei singoli target sull'initiator per fare un
"volume" di una certa dimensione. Questo permette alta velocita, in
quanto il carico viene ripartito su 4 macchine, e su N HDD, e allo
stesso tempo in alta velocita su N schede rete.

Pensi che iscsi possa essere applicato anche a questo concetto? Io credo
che si possa applicare in tale ambito, cio comporterebbe una complessità
elevata ma se il sistema è ben progettato sarebbe (secondo me) una
soluzione a dir poco fantastica.
--
Per REVOCARE l'iscrizione alla lista, inviare un email a
debian-italian-***@lists.debian.org con oggetto "unsubscribe". Per
problemi inviare un email in INGLESE a ***@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@gmail.com
Domenico Rotella
2011-03-26 12:00:03 UTC
Permalink
Il giorno 25 marzo 2011 19:41, Alessandro Baggi
Post by Alessandro Baggi
Comincio a fare un po di confusione.
Se dico qualcosa di sbagliato correggimi.
Con una SAN, (tralasciando le schede di rete) abbiamo un initiator e dei
target, in sostanza il target è colui che da i dischi e l'initiator è quello
che lo dovrebbe gestire. L'utilizzo di una SAN è legato alla velocita con
cui i dati vengono trasmessi, e questo non fa forza solo sulle schede di
rete ma anche hdd, processori ecc..., ecco per cui utilizziamo molteplici
macchine per lo scopo.
Ovvio tutto contribuisce alla velocità della trasmissione dei dati, ricorda
ma credo sia superfluo dirlo che un target può essere associato ad un solo
initiator quindi ogni risorsa esportata via iscsi può essere gestita da un
solo initiator alla volta...
Post by Alessandro Baggi
1) Avere N macchine, ognuna con uno storage per una determinata sezione, e
quindi "aggregarli" su un unico sistema. Ma questa tipologia puo essere
schivata.
In realtà lo scopo reale è questo, da una parte hai un initiator, magari un
server non troppo performante, magari virtuale, cui non è possibile
collegare un grande storage, o comunque è poco utile, in quanto in caso di
guasto al server ti trovi senza server e senza storage, nel caso siano
risorse diverse, puoi sempre agganciare lo spazio disco ad un server di
backup o di emergenza e limitare il tempo di down; dall'altra hai una SAN
pensata apposta per fornire storage, a seconda della configurazione con
svariati slot per hard disk hot swap, raid hw, rete ed alimentazione
ridondata, con un s.o. customizzato, come i QNAP per esempio che occupano
pochissime risorse.
Post by Alessandro Baggi
2) (questa secondo me è la piu utile) Avere N macchine, ognuna con N hdd,
per creare una unica grande rete che raggiunge dimensioni di storage molto
molto elevate, questo dovrebbe essere uno dei motivi per cui si dice low
cost e con prestazioni abbastanza elevate.
Per la prima ipotesi, diciamo che la possiamo tralasciare, avere N server
storage e aggregarli su una unica macchina, non mi sembra poi cosi utile, in
fondo lo abbiamo gia il server, che fa il lavoro che deve fare, anzi, se
l'initiator fallisce abbiamo un unico punto di fallimento, se cade
l'initiator cade tutta la rete.
iscsi ci permette per cui di dare all'initiator un certo numero di dischi,
sia questo un hdd normale, sia un md, o un lvm.
Prendiamo in considerazione la seconda ipotesi.
Ora la domanda che mi pongo è: e se volessi creare un sistema con uno
storage di dimensioni molto elevate (fantastichiamo petabyte, oppure 3000
TB) per un qualche scopo, come fare per ovviare a questo? Fino ad ora non ho
mai sentito di singole macchine che hanno controller in grado di fare cio
(parliamo sempre di bassi costi, non di mainframe), per ora penso che la
soluzione possa essere un Cluster di hdd, e per le operazioni servono sempre
CPU, RAM etc...e penso che con iscsi si possa fare molto facilmente, ovvio
diventa complesso da gestire ma si possono creare sempre sistemi di
automazione.
Per la questione dei raid, su ogni singola macchina (target), dovremmo
mettere i dischi in raidN per fornire una qualche ridondanza per i dati,
sulla singola macchina, in quanto ora sono le singole macchine a fare da
point of failure oltre che all'initiator. Per cui se si rompe una macchina,
o un hdd, o qualche componente e la macchina diventa inusabile la rete cade
(mi riferisco agli hdd), sempre nel caso di un unico grande storage. Ma se
invece provvediamo a fornire una ridondanza in rete? Per esempio un raid 1
tra due dev di due diverse macchine (la sincronizzazione verra tra i due hdd
via iscsi e vie rete) Facciamo conto che drbd non esista, anche se penso che
si basi sullo stesso principio. Bhe penso che se cade la prima abbiamo
sempre la seconda, ovvio che si abbasserebbero le performance fino alla
risincronizzazione.
Quello che ho pensato io è: abbiamo 4 target e un initiator. Sui target
abbiamo 12 HDD che configuriamo con un raid5 hardware o software che sia
(tralasciamo i livelli dei raid) per cui vedremo /dev/md0 sui target,
sull'initiator abbiamo invece i dev importati sdb, sdc, sdd e sde. E fin qui
tutto bene. Supponiamo ora di volere un unico gigante archivio per esempio
per lo storage di siti e materiale relativo ai siti, per una webfarm. Il
miglior modo per poter fare cio sarebbe quello di condividere i raid dei
singoli target sull'initiator per fare un "volume" di una certa dimensione.
Questo permette alta velocita, in quanto il carico viene ripartito su 4
macchine, e su N HDD, e allo stesso tempo in alta velocita su N schede rete.
Pensi che iscsi possa essere applicato anche a questo concetto? Io credo
che si possa applicare in tale ambito, cio comporterebbe una complessità
elevata ma se il sistema è ben progettato sarebbe (secondo me) una soluzione
a dir poco fantastica.
Premesso che tutto è possibile, per lo meno a livello di test, studio ecc...
credo ci sia un problema alla base, supposto che un azienda abbia la
necessità di vari petabyte di spazio disco, credo che dovrebbe avere anche
le risorse per acquistare dell'hardware adeguato, ci sono SAN di IBM ed HP
tanto per citare alcuni nomi conosciuti che teoricamente non hanno limiti di
espandibilità a livello di spazio disco. In situazioni come la tua si
dovrebbe pensare ad un cluster gestito bene, capisci che si io importo via
iscsi 4 nodi da 10 TB per ottenerne uno da 40TB devo necessariamente creare
un lvm o un raid, magari raid0 per non perdere spazio, ma in caso di raid
degradato ? Quello creato sull'initiator segnala lo status che però è da
attribuire ad almeno uno dei 4 nodi, per cui devi "smontare" gradualmente
almeno 2 raid, se fossero 2 dischi su 2 nodi diversi avresti perso tutti i
dati :( poi considera il tempo di ricostruzione dell'array degradato.... di
40TB a dir poco ingestibile in realtà di produzione.
Spero di essere stato chiaro...
Ciao
Domenico.
--
-------
"Eliminato l'impossibile ciò che resta per quanto improbabile è la verità".
Conan Doyle.
Alessandro Baggi
2011-03-26 13:07:02 UTC
Permalink
Post by Domenico Rotella
Il giorno 25 marzo 2011 19:41, Alessandro Baggi
Comincio a fare un po di confusione.
Se dico qualcosa di sbagliato correggimi.
Con una SAN, (tralasciando le schede di rete) abbiamo un initiator
e dei target, in sostanza il target è colui che da i dischi e
l'initiator è quello che lo dovrebbe gestire. L'utilizzo di una
SAN è legato alla velocita con cui i dati vengono trasmessi, e
questo non fa forza solo sulle schede di rete ma anche hdd,
processori ecc..., ecco per cui utilizziamo molteplici macchine
per lo scopo.
Ovvio tutto contribuisce alla velocità della trasmissione dei dati,
ricorda ma credo sia superfluo dirlo che un target può essere
associato ad un solo initiator quindi ogni risorsa esportata via iscsi
può essere gestita da un solo initiator alla volta...
Penso che gli scopi per cui si usa iscsi possano essere
1) Avere N macchine, ognuna con uno storage per una determinata
sezione, e quindi "aggregarli" su un unico sistema. Ma questa
tipologia puo essere schivata.
In realtà lo scopo reale è questo, da una parte hai un initiator,
magari un server non troppo performante, magari virtuale, cui non è
possibile collegare un grande storage, o comunque è poco utile, in
quanto in caso di guasto al server ti trovi senza server e senza
storage, nel caso siano risorse diverse, puoi sempre agganciare lo
spazio disco ad un server di backup o di emergenza e limitare il tempo
di down; dall'altra hai una SAN pensata apposta per fornire storage, a
seconda della configurazione con svariati slot per hard disk hot swap,
raid hw, rete ed alimentazione ridondata, con un s.o. customizzato,
come i QNAP per esempio che occupano pochissime risorse.
2) (questa secondo me è la piu utile) Avere N macchine, ognuna con
N hdd, per creare una unica grande rete che raggiunge dimensioni
di storage molto molto elevate, questo dovrebbe essere uno dei
motivi per cui si dice low cost e con prestazioni abbastanza elevate.
Per la prima ipotesi, diciamo che la possiamo tralasciare, avere N
server storage e aggregarli su una unica macchina, non mi sembra
poi cosi utile, in fondo lo abbiamo gia il server, che fa il
lavoro che deve fare, anzi, se l'initiator fallisce abbiamo un
unico punto di fallimento, se cade l'initiator cade tutta la rete.
iscsi ci permette per cui di dare all'initiator un certo numero di
dischi, sia questo un hdd normale, sia un md, o un lvm.
Prendiamo in considerazione la seconda ipotesi.
Ora la domanda che mi pongo è: e se volessi creare un sistema con
uno storage di dimensioni molto elevate (fantastichiamo petabyte,
oppure 3000 TB) per un qualche scopo, come fare per ovviare a
questo? Fino ad ora non ho mai sentito di singole macchine che
hanno controller in grado di fare cio (parliamo sempre di bassi
costi, non di mainframe), per ora penso che la soluzione possa
essere un Cluster di hdd, e per le operazioni servono sempre CPU,
RAM etc...e penso che con iscsi si possa fare molto facilmente,
ovvio diventa complesso da gestire ma si possono creare sempre
sistemi di automazione.
Per la questione dei raid, su ogni singola macchina (target),
dovremmo mettere i dischi in raidN per fornire una qualche
ridondanza per i dati, sulla singola macchina, in quanto ora sono
le singole macchine a fare da point of failure oltre che
all'initiator. Per cui se si rompe una macchina, o un hdd, o
qualche componente e la macchina diventa inusabile la rete cade
(mi riferisco agli hdd), sempre nel caso di un unico grande
storage. Ma se invece provvediamo a fornire una ridondanza in
rete? Per esempio un raid 1 tra due dev di due diverse macchine
(la sincronizzazione verra tra i due hdd via iscsi e vie rete)
Facciamo conto che drbd non esista, anche se penso che si basi
sullo stesso principio. Bhe penso che se cade la prima abbiamo
sempre la seconda, ovvio che si abbasserebbero le performance fino
alla risincronizzazione.
Quello che ho pensato io è: abbiamo 4 target e un initiator. Sui
target abbiamo 12 HDD che configuriamo con un raid5 hardware o
software che sia (tralasciamo i livelli dei raid) per cui vedremo
/dev/md0 sui target, sull'initiator abbiamo invece i dev importati
sdb, sdc, sdd e sde. E fin qui tutto bene. Supponiamo ora di
volere un unico gigante archivio per esempio per lo storage di
siti e materiale relativo ai siti, per una webfarm. Il miglior
modo per poter fare cio sarebbe quello di condividere i raid dei
singoli target sull'initiator per fare un "volume" di una certa
dimensione. Questo permette alta velocita, in quanto il carico
viene ripartito su 4 macchine, e su N HDD, e allo stesso tempo in
alta velocita su N schede rete.
Pensi che iscsi possa essere applicato anche a questo concetto? Io
credo che si possa applicare in tale ambito, cio comporterebbe una
complessità elevata ma se il sistema è ben progettato sarebbe
(secondo me) una soluzione a dir poco fantastica.
Premesso che tutto è possibile, per lo meno a livello di test, studio
ecc... credo ci sia un problema alla base, supposto che un azienda
abbia la necessità di vari petabyte di spazio disco, credo che
dovrebbe avere anche le risorse per acquistare dell'hardware adeguato,
ci sono SAN di IBM ed HP tanto per citare alcuni nomi conosciuti che
teoricamente non hanno limiti di espandibilità a livello di spazio
disco. In situazioni come la tua si dovrebbe pensare ad un cluster
gestito bene, capisci che si io importo via iscsi 4 nodi da 10 TB per
ottenerne uno da 40TB devo necessariamente creare un lvm o un raid,
magari raid0 per non perdere spazio, ma in caso di raid degradato ?
Quello creato sull'initiator segnala lo status che però è da
attribuire ad almeno uno dei 4 nodi, per cui devi "smontare"
gradualmente almeno 2 raid, se fossero 2 dischi su 2 nodi diversi
avresti perso tutti i dati :( poi considera il tempo di ricostruzione
dell'array degradato.... di 40TB a dir poco ingestibile in realtà di
produzione.
Spero di essere stato chiaro...
Ciao
Domenico.
--
-------
"Eliminato l'impossibile ciò che resta per quanto improbabile è la verità".
Conan Doyle.
Ciao domenico, sei stato chiarissimo, i miei dubbi sono stati chiariti.
Grazie per il tempo.

Alla prossima
--
Per REVOCARE l'iscrizione alla lista, inviare un email a
debian-italian-***@lists.debian.org con oggetto "unsubscribe". Per
problemi inviare un email in INGLESE a ***@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@gmail.com
Continue reading on narkive:
Loading...