Live Mesh vs Live Sync

Mi appresto a lavorare più spesso da una postazione remota rispetto all’ufficio ed ho necessità di condividere cartelle di documenti con i resto del team in maniera semplice.

Se seguite il mio blog sapete che utilizzo molto linux, ma come “desktop operativo” preferisco ancora windows.

Facendo un po’ di ricerche ho scoperto che nella suite “Windows Live” compaiono due strumenti: “Windows Live Sync” e “Windows Live Mesh”.

Se avete sentito parlare di “Windows Live FolderShare” vi dico subito che è il nome precedente di Live Sync e quindi non si tratta di un terzo strumento.

Cosa c’è di uguale?

Innanzi tutto entrambi gli strumenti sono gratuiti ed entrambi richiedono un account windows live che può essere creato gratuitamente sul sito microsoft. Entrambi i programmi risiedono nella traybar e notificano eventuali novità/attività modificando l’icona.

Cosa c’è di differente

La differenza fondamentale sta nel fatto che “live sync” crea una rete di “peers” e non ha un server centralizzato mentre “live mesh” utilizza un server centrale. Questa differenza è la causa principale di tutte le altre.

Con Live Sync perchè un documento venga sincronizzato è necessario che i peers siano (almeno ogni tanto) collegati contemporaneamente: se voleste quindi sincronizzare due vostri pc che stanno accesi alternativamente (ufficio e casa) non potrete usare questo sistema.

Live Mesh utilizza un server centrale che opera come se fosse un peer sempre presente: questo permette di utilizzarlo come sistema di backup dei propri dati che sono accessibi sempre e comunque online utilizzando il proprio account windows live (con un limite di 5GB)

Live Mesh aggiunge poi integrazioni con explorer per mostrare “commenti” aggiunti alle cartelle dai vari utenti (e per pubblicare note) e anche un sistema di accesso al desktop remoto, che però necessita dell’installazione di una activex particolare e di utilizzare quindi Internet Explorer (preferisco attivare il classico desktop remoto, che è disponibile su qualunque xp/vista senza installare niente).

Live Mesh utilizza molte più risorse (hanno un po’ esagerato con le skin, secondo me) di Live Sync che risulta invece essere un programmino estremamente snello!

Per Live Mesh sembra esistere anche il client “Windows Mobile” con il quale potete mantenere sincronizzato anche il vostro palmare/telefono windows. Io uso Symbian (Nokia), quindi questa funzionalità non mi sposta.

Usando Live Sync solo i peer vedranno il contenuto dei files che non transita su nessun server Microsoft e non viene memorizzato in alcun server microsoft. L’elenco dei documenti, invece, sembra sia memorizzato su di un server.

Conclusione

In conclusione non c’è un vincitore: a me piacerebbe aggiungessero a LiveSync la possibilità di creare un peer online accessibile via web così da aggiungere l’unica funzionalità a mio parere mancante. Se il protocollo di comunicazione tra i peer fosse open (non credo) sarebbe possibile fare una applicazione server per automatizzare tutto questo (magari su linux) e, anche meglio, sarebbe possibile usare come server un proprio dedicato evitando così che i dati risiedano su server microsoft che potrebbe non farci piacere! Ovviamente se avete un server windows sempre online potete fare questo giochino con LiveSync ed ottenere quello che secondo me sarebbe il miglior risultato: purtroppo come sapete uso windows solo sui desktop mentre sui server rigorosamente solo macchine linux/freebsd.

Alternative

DropBox, iFolder, PowerFolder. Mi sembrano tutti più pesanti in termini di risorse e le applicazioni che rimangono caricate sempre dovrebbero essere più leggere possibile. Forse proverò iFolder per via dell’esistenza di un server linux.

Nessun articolo simile

Ricetta definitiva per l'USB

Nelgi ultimi anni mi sono imbattuto frequentemente in computer con Windows XP che non rilevavano correttamente alcune periferiche USB. Al collegamento della periferica si sente il classico suono bitonale che avverte che windows ha rilevato la periferica, ma poi questa non funziona correttamente. Su altri computer la stessa periferica funzionava correttamente.

Nella maggior parte dei casi il problema era che la periferica era stata collegata prima di installare i suoi driver. E’ importante leggere le istruzioni prima di collegare tali periferiche perchè la maggior parte richiede l’installazione dei driver prima del collegamento ma alcune preferiscono la procedura inversa.

Quindi prima di installare una stampante, una fotocamera, una videocamera, una scheda sonora USB, un telefono USB, un dispositivo di acquisizione dati, etc, leggete le istruzioni!

Se, invece, avete già fatto il danno, questa è la procedura che in molti casi (ma non in tutti) mi ha portato a risolvere il problema.

La procedura è complicata e può danneggiare il sistema operativo, quindi fate il backup dei dati e seguitela solo se pensate di potervela cavare. L’unica alternativa provata a questa procedura è la reinstallazione di Windows XP.

Passo 1: Preparativi

1. Scollegare tutte le periferiche USB (ad eccezione di tastiera e mouse)
2. Avviare XP in modalità provvisoria (premendo F8 durante l’accensione del computer).

Passo 2: Rimuovere tutti i dispositivi “nascosti”

1. Cliccare Avvio, Esegui. Digitale cmd e premere OK.
2. Appare una schermata nera per il prompt dei comandi
3. Scrivere “set DEVMGR_SHOW_DETAILS=1″ (senza apici) e premere INVIO.
4. Scrivere “set DEVMGR_SHOW_NONPRESENT_DEVICES=1″ (senza apici) e premere INVIO.
5. Scrivere “start devmgmt.msc” (senza apici) e premere INVIO.
6. Cliccare su “Visualizza” “Mostra i disposibivi nascosti” (non ricordo la digitura esatta, non ho XP sotto mano)
7. Clicca “+” per espandere i vari gruppi e rimuovere tutto ciò che ha a che fare con l’ “USB” ed eventualmente ciò che riporta nomi che hanno a che fare con Hi-Pro.

Spesso in questo frangente smette dik funzionare il mouse: in quei casi bisognerebbe riuscire a copletare la procedura con la sola tastiera
la cosa richiedere un uso sapiente delle scorciatoie di windows, ne elenco alcune:

CTRL-ESC apre il menu di avvio,
TAB e le frecce permettono di muovere la selezione,
INVIO di cliccare ciò che è selezionato,
ALT di aprire il menu della finestra attiva.
ALT-TAB di cambiare la finestra attiva

Passo 3: Rimozione di tutti i file oem*.inf

1. Cliccare Avvio, Esegui e digitare “cmd” (senza apici)
2. Nel prompt dei comandi eseguire questi comandi premendo invio dopo ognuno:

   cd \windows\inf
   ren infcache.1 *.old
   ren oem*.inf *.old
   del C:\windows\setupapi.log
   exit

Passo 4: Rimozione chiavi di registro di HKEY_LOCAL_MACHINE/Enum/USB che cominciano con VID

La rimozione delle chiavi VID dal registro farà si che i dispositivi vengano rilevati nuovamente al riavvio.

In questo punto bisognerebbe fare attenzione a non rimuovere i VID di tastiera e mouse USB ma a memoria non mi ricordo come riconoscerli.

1. Cliccare Avvio, Esegui. Digitare “regedit” (senza apici) e cliccare oK. Si aprirà l’editor del registro di sistema.
2. Navigare l’albero fino a HKEY_LOCAL_MACHINE\System\CurrentControlSet\Enum\USB
3. Evidenziare e canellare tutte le chiavi che cominciano per VID_

Nel caso venga dato un errore di permessi insufficienti o impossibilità di eliminare le voci:

1. Tasto destro del mouse sulla chiave da cancellare e click su “Permessi” (vado sempre a memoria). Aprirà la finestra dei permessi.
2. Con “Everyone” (forse si chiama “Tutti” in italiano) selezionato nella casella utenti e gruppi, selezionare “Controllo completo” nella lista permessi.
3. Cliccare “Applica” e poi OK.

A questo punto dovrebbe essere possibile cancellare la chiave. Ripetere per tutte le chiavi poi spegnere il computer.

Passo 5: Riavvio e reinstallazione drivers

Al riavvio il computer dovrà reinstallare i driver per tutte le periferiche e potrebbe chiedere CD di windows e dei driver.
Installare i driver delle periferiche *prima* di collegare i dispositivi e riavviare il computer dopo aver collegato ed installato una periferica prima di collegare quella successiva.

Nessun articolo simile

In OVH questa cosa non è sufficiente poichè spesso le macchine sono in classi C differenti e separate da router. E’ necessario quindi comunicare ad OVH che vogliamo “oscillare” un IP failover da un server ad un altro così che OVH possa aggiornare le regole di routing interne.

Normalmente questa operazione viene fatta dall’interfaccia web del manager OVH, ma è possibile farla anche tramite le API che OVH mette a disposizione con il protocollo SOAP.

Gestione IP Failover su Manager v3 OVH

Requisiti

Le api vengon utilizzate via SOAP e quindi quasi tutti i linguaggi di programmazione che dispongono di una libreria client SOAP possono essere utilizzati.

Nel mio piccolo ho provato python 2.4 con la libreria SOAPpy e PHP 5.1.6 con il SoapClient integrato ed ho riscontrato problemi con entrambe.

Sembra che il SoapClient di PHP abbia un bug critico che gli impedisce di funzionare con il wsdl di OVH. Il bug sembra corretto in PHP 5.2.6 che però non posso utilizzare.

Procedo quindi con python così da non interferire con PHP che è già presente nel sistema e configurato correttamente.

Questi i pacchetti presenti nella mia Centos 5.3:
SOAPpy-0.11.6-5.el5 e python-2.4.3-24.el5

Esempio e Problema

Prendendo ad esempio il generatore di codice client di OVH generiamo il codice python per vedere l’elenco dei failover associati

#!/usr/bin/python
import pprint
from SOAPpy import WSDL

soap = WSDL.Proxy('https://www.ovh.com/soapi/soapi-re-1.3.wsdl')
#login
session = soap.login('###NIC###-ovh', '###PASS###', 'it', 0)
print "login successfull"
#dedicatedFailoverList
result = soap.dedicatedFailoverList(session, '###NOMEDEDICATO###')
print "dedicatedFailoverList successfull"
pp = pprint.PrettyPrinter(indent=4)
pp.pprint(result) # your code here ...
#logout
soap.logout(session)
print "logout successfull"

ottenendo però questo risultato inaspettato:

login successfull
Traceback (most recent call last):
File "./example.py", line 13, in ?
result = soap.dedicatedFailoverList(session, '###NOMEDEDICATO###')
File "/usr/lib/python2.4/site-packages/SOAPpy/Client.py", line 453, in __call__
return self.__r_call(*args, **kw)
File "/usr/lib/python2.4/site-packages/SOAPpy/Client.py", line 475, in __r_call
self.__hd, self.__ma)
File "/usr/lib/python2.4/site-packages/SOAPpy/Client.py", line 379, in __call
p, attrs = parseSOAPRPC(r, attrs = 1)
File "/usr/lib/python2.4/site-packages/SOAPpy/Parser.py", line 1006, in parseSOAPRPC
t = _parseSOAP(xml_str, rules = rules)
File "/usr/lib/python2.4/site-packages/SOAPpy/Parser.py", line 985, in _parseSOAP
parser.parse(inpsrc)
File "/usr/lib/python2.4/site-packages/_xmlplus/sax/expatreader.py", line 109, in parse
xmlreader.IncrementalParser.parse(self, source)
File "/usr/lib/python2.4/site-packages/_xmlplus/sax/xmlreader.py", line 123, in parse
self.feed(buffer)
File "/usr/lib/python2.4/site-packages/_xmlplus/sax/expatreader.py", line 216, in feed
self._parser.Parse(data, isFinal)
File "/usr/lib/python2.4/site-packages/_xmlplus/sax/expatreader.py", line 363, in end_element_ns
self._cont_handler.endElementNS(pair, None)
File "/usr/lib/python2.4/site-packages/SOAPpy/Parser.py", line 234, in endElementNS
kind = (self._prem[kind[:i]], kind[i + 1:])
KeyError: u'typens'

Segnalando il problema a bugkillers@ml.ovh.net mi viene risposto velocemente che si tratta di un bug della libreria SOAP di Python (SOAPpy) presente fino alla versione 0.20 compresa. Da notare che mentre scrivo l’ultima release di SOAPpy è la 0.19 e risale al 2005. Si trovano alcuni rpm della 0.20 che probabilmente si riferiscono alla rc1 rilasciata nel 2007 ma anche questi contengono il bug di cui sopra!

L’unica è quindi utilizzare la versione di sviluppo che scarichiamo e della quale facciamo un tarball:

svn export https://pywebsvcs.svn.sourceforge.net/svnroot/pywebsvcs/trunk/SOAPpy/ SOAPpy-0.12.0
tar -zcf SOAPpy-0.12.0-dev.tar.gz SOAPpy-0.12.0
rm -rf SOAPpy-0.12.0
mv SOAPpy-0.12.0-dev.tar.gz /usr/src/redhat/SOURCES

A questo punto inseriamo il file spec appositamente creato e facciamo il build dei pacchetti (sorgente e binario) e installiamo il pacchetto appena creato.

cd /usr/src/redhat/SPECS
wget http://digg.it/wp-content/uploads/2009/06/SOAPpy-0.12.0.spec
rpmbuild --define="dist .el5" --define "centos 5" -ba SOAPpy-0.12.0.spec
rpm -Uvh /usr/src/redhat/RPMS/noarch/SOAPpy-0.12.0-dev.el5.noarch.rpm

Il pacchetto risultante lo trovate qui: SOAPpy-0.12.0-dev.el5.noarch.rpm

Altri problemi

Un ulteriore inconveniente del metodo API utilizzabile è che per basculare un IP dobbiamo prima sapere a quale server è assegnato in questo momento.

La mia necessità, invece, è quella che un server, in autonomia e senza conoscenze esterne possa richiedere un IP failover ed ottenerlo.

Per far questo quindi ho creato uno script che una volta loggato sulle API richiede l’elenco dei dedicati associati al cliente e cerca l’IP specificato in tutti i server. Se lo trova già associato al server giusto non fa nulla, se invece lo trova associtato ad un altro server effettua la chiamata per oscillarlo verso se stesso.

Conclusioni

Lo script creato lo trovate qui: getfailover.py

E’ abbastanza spartano ma per ora fa quello che mi serve. Utilizzo questo script in combinazione con heartbeat per permettere al mio cluster OVH di oscillare automaticamente in caso di problemi.

Related posts:

1. Utilizzare IP failover su un RPS Gli RPS di OVH vengono consegnati con 2 IP, di...

14/05/2009: richiesta F5 7M/384 mini
21/05/2009: appuntamento telefonico Telecom per il giorno dopo!
22/05/2009: tecnico telecom 3 ore per infilare un cavo e giri vari in centrale e derivazioni per far finalmente sentire la portante. Mentre lui misurava con lo “strumento” la mia linea alla mia affermazione “siamo distanti dalla centrale, non andrà molto veloce!” ha prontamente replicato “la distanza non è elevata, è che ci sono parecchie derivazioni vecchie e marce“.
22/05/2009: NGI mi manda login/password dichiarando la linea attivata.
22/05/2009: la sera riesco finalmente a collegare il router ma non aggancia.

Date/Time  	Facility  	Severity  	Message
Jan 1 00:01:25 	user 	crit 	kernel: ADSL G.994 training
Jan 1 00:01:26 	user 	crit 	kernel: ADSL G.992 started
Jan 1 00:01:31 	user 	crit 	kernel: ADSL G.992 channel analysis
Jan 1 00:01:36 	user 	crit 	kernel: ADSL G.994 training
Jan 1 00:01:41 	user 	crit 	kernel: ADSL G.992 channel analysis
Jan 1 00:01:46 	user 	crit 	kernel: ADSL G.994 training
Jan 1 00:01:51 	user 	crit 	kernel: ADSL G.992 started
Jan 1 00:01:56 	user 	crit 	kernel: ADSL G.992 channel analysis
Jan 1 00:02:01 	user 	crit 	kernel: ADSL G.994 training
Jan 1 00:02:06 	user 	crit 	kernel: ADSL G.992 channel analysis
Jan 1 00:02:11 	user 	crit 	kernel: ADSL G.994 training
Jan 1 00:02:16 	user 	crit 	kernel: ADSL G.992 started
Jan 1 00:02:21 	user 	crit 	kernel: ADSL G.992 channel analysis
Jan 1 00:02:26 	user 	crit 	kernel: ADSL G.994 training
Jan 1 00:02:32 	user 	crit 	kernel: ADSL G.992 channel analysis
Jan 1 00:02:38 	user 	crit 	kernel: ADSL G.994 training
Jan 1 00:02:41 	user 	crit 	kernel: ADSL G.992 started
Jan 1 00:02:46 	user 	crit 	kernel: ADSL G.992 channel analysis
Jan 1 00:02:51 	user 	crit 	kernel: ADSL G.994 training
Jan 1 00:02:56 	user 	crit 	kernel: ADSL G.992 channel analysis
Jan 1 00:03:01 	user 	crit 	kernel: ADSL G.994 training
Jan 1 00:03:06 	user 	crit 	kernel: ADSL G.992 started
Jan 1 00:03:11 	user 	crit 	kernel: ADSL link down
Jan 1 00:03:16 	user 	crit 	kernel: ADSL G.994 training
Jan 1 00:03:21 	user 	crit 	kernel: ADSL G.992 channel analysis
Jan 1 00:03:22 	user 	crit 	kernel: Unable to send OAM cell over VPI/VCI
8/35 (error 9).
Jan 1 00:03:22 	user 	crit 	kernel: Unable to send OAM cell over VPI/VCI
8/35 (error 9).
Jan 1 00:03:26 	user 	crit 	kernel: ADSL G.994 training

22/05/2009: Rispondo all’email di attivazione segnalando il non funzionamento con il log del kernel. Lascio il router attaccato, così vedo la lucina dell’ADSL che lampeggia (training) e mi accorgo se per caso sistemano.
23/05/2009: (sabato). La mattina trovo il router connesso così controllo subito e vedo che è connesso a 320kbps downstream / 480 upstream. 320kbps ???? Si era connesso la notte, dopo 8 ore di tentativi. Così nel weekend rimane connesso a 320, o a volte 384, segnalando comunque vari CRC.
25/05/2009: 3 giorni dopo mi rispondono che loro non possono aiutarmi e che devo aprire un ticket su assistenza! Per loro la linea è attiva, quindi si tratta di un guasto! Apro subito il ticket allegando i dati forniti dal router:

Downstream 320kbps

28/05/2009: finalmente, dopo 6 giorni di linea connessa a 320kbit/384kbit o per diverse ore completamente disconnessa il router aggancia a 2500kbps. Il 28 faccio diverse prove sulla mia “nuova linea” finalmente funzionante e riesco anche a connettermi a 3.1mbps senza problemi di instabilità.

28/05/2009: Alle 23.30 stavo finalmente gioiendo della mia nuova linea “funzionante” quando cade la connessione e si riconnette a 320kbps per poi morire definitivamente dopo 30 minuti.

30/05/2009: A linea connessa a 320kbps NGI mi chiude il ticket: “il fornitore ha chiuso la segnalazione di guasto inerente la sua linea. Da nostre verifiche il problema sembra rientrato.” Quali verifiche visto che sono connesso a 320kbps e che tutta la notte non si connetteva??

01/06/2009: NGI “abbiamo chiesto un ulteriore verifica a telecom Italia sulla sua linea adsl.“

03/06/2009: Dopo altri 6 giorni di connessione con le stampelle o connessione assente del tutto decido di dedicare un po’ di tempo a capirne di più. Mi preoccupo quindi di testare la linea con DMT, ottimo strumento di analisi, che sul firmware originale dell’asus wl-600g dice l’SNR margin di ciascun tono e che mi permette di tracciare l’andamento dell’SNRM con questo il risultato:

Risultati di DMT su linea "rotta"

Si nota come l’SNRM abbia notevoli fluttuazioni e come la curva dell’SNR db per tono al posto degli aspettati quasi 40db al centro dello spettro ha un bel buco di SNR -11db: A 560Khz il rumore è più ampio del segnale, tutto il gap tra i 200 e i 500khz (normalmente fascia privilegiata) non arriva a 20db.

Vista l’evidenza del problema anomalo scrivo subito ad NGI convinto che con un grafico del genere possano capire il problema immediatamente (o farlo capire a Telecom) per arrivare ad una veloce soluzione (sottolineo che il mio tono nei confronti di NGI è collaborativo e non incazzato, per ora).

04/06/2009: Ricevo una telefonata da un tecnico Telecom che mi dice che dalla centrale misurano un SNR di 20db, che a suo dire è molto buono. Cerco di spiegargli la storia dei 560Khz e della curva dell’SNR per tono ma vengo ignorato (o forse non compreso). Conferma, però, che è strano che con 20db il mio router si colleghi a 320kbps e dice che se la notte non si collega per ora è colpa di NGI (???). Poi interrompono la linea per fare dei test.

Dopo un po’ mi richiama e chiede di venire a fare dei test dal mio lato pensando che possa essere il mio modem ad avere problemi. Il suo strumento da gli stessi identici problemi e si collega a 320kbps. Gli faccio vedere i miei grafici DMT ma l’unico risultato è un “bello quel programma!“. Dopo un paio d’ore di telefonate in centrale e tentativi mi liquida dicendo che la loro linea funziona e che è un problema di instradamento ATM di NGI. (non sono il massimo esperto in materia ma che un problema di instradamento ATM possa variare le curve dell’SNR del loop DSL mi suona “alternativo”, ma mica posso mettermi a litigare con un tecnico Telecom, ditta con la quale non ho alcun contratto a cui appellarmi!).  Lo saluto e mi dice che girerà il guasto a chi di competenza e che io non devo fare nulla.

Nel frattempo riesco a provare un secondo router (identico) con però il firmware aggiornato all’ultima versione compilata da TheDrake che include un driver adsl per il chip broadcom più aggiornato (versione A2p023k proveniente dal modem USR9113) e che scambia molte più informazioni con DMT.

Verso le 14.40, ad un ennesima richiesta di resync fatta con DMT, il router si collega a più di 2mbps, per poi arrivare a 3168 come si vede da questo grafico:

Grafico degli SNR per tono e allocazione di bit per tono di una linea che funziona.

Con il nuovo firmware non solo riesco a vedere gli SNR per tono, ma riesco anche a visualizzare quanti bit vengono allocati su ugnuno e quali toni quindi vengono usati. Questo è il grafico di una ADSL funzionante (vedete che al centro è quasi 40db?) e con un SRN margin estremamente stabile (vedete quanto è piatta la linea del terzo grafico?). La buona notizia è che è la mia linea e quindi forse il tecnico Telecom ha passato la palla alle persone giuste ed hanno capito e risolto il problema!

06/06/2009: al mio aggiornato in cui segnalavo che dal pomeriggio aveva cominciato ad andare bene NGI mi risponde “la Sua pratica risulta tutt’ora in lavorazione lato Telecom Italia. Le faremo sapere qulacosa non appena l’intervento verrà chiuso“

07/06/2009: Ore 14.40. Dopo 3 giorni esatti di ottimo funzionamento cade la linea per riconnettersi a 384kbps. Controllo immediatamente con DMT e il grafico dei toni è tornato ad essere quello brutto che avevo all’inizio. Alle 17 cade proprio la linea e non si riconnette più. Armato del nuovo firmware configuro il router per fare un sync “più estremo” accettando un margine segnale rumore di pochi decibel (adslctl configure –snr 10) riesco a fare il sync a circa 1mbps con un SNRM di 7db che però calano inesorabilmente e costantemente fino a mezzanotte in cui con 4.5db di SNRM mi cade la linea dopo un’ondata di errori CRC. A questo punto non mi connetto più con nessuno dei due router e con nessuna impostazione.

08/06/2009: Segnalo a NGI il problema e ricevo come risposta: “il fornitore afferma di aver risolto il problema sul suo circuito adsl. Da nostre verifiche il problema persiste, quindi abbiamo richiesto una nuova verifica.“.

09/06/2009: NGI mi dice che: “il fornitore ha chiuso la segnalazione di guasto inerente la Sua linea sostenendo la necessità di effettuare un downgrade della stessa a 1280/256 rate-adaptive causa eccessiva distanza da centrale.” Continua poi proponendomi di accettare per iscritto o di procedere alla disdetta/rimborso.

Cerco così di spiegare al tecnico NGI (quelli che mi rispondo all’assistenza sono tecnici?) tutta la trafila perchè convenga con me che non si tratta di un banale problema di distanza dalla centrale ed SNR ma di altro.

Riassumendo

La mia linea ha presentato due stati:

• Stato 0 – Linea non funzionante: La linea si collega a 320kbit (a meno che io non faccia hack del router in modo da accettare un SNRm inferiore ai 10db, che è lo standard del router) e a volte per 7 ore non si collega proprio. l’SNR margin oscilla del 30% nell’arco di pochi minuti. Più volte, nonostante connesso a 320kbit tra le 22 e le 2 di notte è caduta la linea per non ricollegarsi più fino alle 6 della mattina.
• Stato 1 – Linea funzionante: la linea si collega a 2-3Mbit e l’SNR margin è stabile senza alcuna oscillazione. Se uso l’hack del router per connetterlo con un SNRmargin più basso vado anche oltre i 4. Se provo a spingerlo a 5 vedo dei CRC. E questo è normalissimo con un a linea distante.

Dal giorno dell’ “ipotetica attivazione” così distribuiti:

• Stato 0 – dal 22 al 27 maggio. Linea down o 320kbit.
  
• Stato 1 - il 28 maggio è andata a 2500-3100kbps correttamente fino a sera
• Stato 0 - dalla sera del 28 maggio al 4 giugno o si connetteva a 320kbit ed ogni tanto cadeva la linea o non si connetteva proprio per varie ore (di solito tutta la notte down).
• Stato 1 – Dalle 14.40 del 4 giugno (2 ore dopo che era stato qui il tenico telecom) si è connesso a 3168 con un SNRm di 11db stabilissimo (nemmeno l’1% di oscillazione) ed è rimasto così fino alle 14.40 del 7 giugno.
• Stato 0 – Dalle 14.40 del 7 giugno la linea è di nuovo a 320 o disconnessa. Oppure si connette ad 1mbit se uso il modem hackato e vado a pochi db di SNRm.

La mia conclusione è che:

• In stato 1 la linea va bene (3-4mbps per un linea distante sono più che accettabili) e non c’è bisogno di limitarla (al limite la limito io aumentando l’SNRm del modem, se voglio).
• Quando è in stato 0 la linea non va per ore, o va a 320kbit (arrivo a 1mbps circa se abbasso l’SNRm ma con parecchi CRC) e comunque spesso cade anche a 320kbit (!!!) e rimane down per notti intere (!!!). Cosa potrebbe risolvere limitare la velocità a 1280 se già a 320 già non funziona??

Spero che NGI voglia seguirmi nella risoluzione del problema, altrimenti l’unica soluzione potrebbe essere quella di chiedere il rimborso ed attivare Alice. Almeno in quel caso potrò lamentarmi direttamente con il fornitore ed evitare di perdere tempo con un intermediario che sembra non ascoltare.

Aggiornamenti

09/06/2009: Dopo altre comunicazioni da NGI che sembra essere d’accordo con Telecom che il problema sia l’SNR dovuto alla distanza dalla centrale rispondo in questo modo:

Secondo me è significativo che per 3 giorni interi (72 ore esatte) la mia linea è stata connessa a più di 3000kbps, e che l’SNRm era piatto come non mai, non una fluttuazione che una! Nel grafico che ho allegato il 5 giugno (dmtm20090605_0920.png) potete vederlo con i vostri occhi.

Questa secondo me è la prova tangibile che il problema non è la distanza poichè posso assicurarvi che in quei 3 giorni casa mia non si è avvicinata alla centrale e l’SNRm non s’è mosso, con grafici di SNR/tono ottimali e costanti durante tutte le 72 ore.

(volendo sdrammatizzare potremmo supporre che io abbia scoperto, guardando molto star trek, come usare la curvatura per far si che la distanza apparente tra me e la centrale diminuisse, ma se fossimo in questo caso converrete con me che vale la pena approfondire che magari diventiamo tutti ricchi!)

Vedremo come prosegue e se NGI saprà confermarsi un’ottimo fornitore quale è stato in questi 8 anni in cui sono sempre stato loro cliente o se vedrò spezzate le mie illusioni.

30/06/2009
Lunedì e martedì scorso la linea è andata bene, poi di nuovo male.

Ho riaperto l’ennesimo guasto con NGI che ha girato la cosa a Telecom. Sabato mattina mi chiama una tecnica telecom dalla centrale per venire da me. Mentre sono al telefono controllo la linea che è completamente down. Glielo riferisco e mi dice che sta staccando e riattaccando fili in centrale.

Dopo pochi minuti la linea si connette bene (3mbit con 12db di SNRm). Quando arriva le faccio presente che dopo poco che mi aveva chiamato si era connesso correttamente. Non attacca nulla mi chiede i due parametri (velocità/SNRm) e chiama col cellulare. Li riferisce e poi esce di casa continuando a chiacchierare. Dopo 10 minuti torna e mi dice che hanno messo la linea in “monitoraggio” così durante il weekend potranno testarla e se ne va (notare che nuovamente in casa mia e nell’ultima scatola di derivazione non è stato fatto niente).

Dopo circa 1 ora la linea torna a funzionare lenta (320kbit, 10db SNRm): chiamo la tecnica al cellulare (visto che mi aveva chiamato perchè non trovava casa mia) e quando glielo riferisco mi chiede “io sono già tornata a forlì (sede telecom), com’è il tempo lì?” le rispondo che “sgocciola” e lei mi dice “comunque oggi non facciamo più niente, la linea è in monitoraggio, lunedì al rientro i tecnici analizzeranno i dati”.

A oggi sono ancora connesso a 320kbit.

Chissà cosa fanno con questo “monitoraggio” e chissà perchè in un mese in cui ho aperto 7 guasti non hanno deciso di “monitare” prima….

01/07/2009
Oggi è venuto un altro tecnico telecom, questa volta con uno strumento diverso dagli altri.

Dalla scatola di derivazione dietro casa ha provato “l’impedenza” (così ha detto) verso il mio router e verso la centrale. Verso il mio router tutto ok, mentre quando ha misurato verso la centrale ha detto “c’è qualcos’altro attaccato a questa linea, devo verificare le altre derivazioni o spostarti su un’altra coppia. comunque lei può andare, non ho bisogno di entrare in casa sua”.

Ovviamente pochi minuti prima che venisse il tecnico la linea si era messa ad andare bene e dopo qualche ora che se ne è andato ha ricominciato ad andare male (ultimamente succede sempre così).

Oggi c’era un sole che spaccava, quindi non può essere un fenomeno legato alla pioggia (ultimamente andava bene solo durante i temporali).

Comunque mi ha richiamato dopo un po’ dicendo che lui non poteva risolvere e che aveva girato il problema ai “tecnici di rete” che mi chiameranno domani o dopodomani per sostituire il doppino. Ora, il doppino da casa mia alla derivazione abbiamo stabilito già cento volte che va bene, spero che con sostituire il doppino intenda che rifanno un pezzo di connessione tra la scatola di derivazione dietro casa mia e la centrale. Non so perchè non abbiano provato a spostarmi su un’altra coppia (in quella scatola di derivazione ne arrivano almeno 16 e ce ne sono 4 occupate), ma questi sono loro segreti di stato!

02/07/2009
Oggi ho trovato la mia linea connessa a 8mbit con 7db di SRNm… allora ho rimesso i canonici 12db e mi connetto a 6.5mbit!!! MOLTO meglio di quando andava bene!

Downstram a 6500kbps

l’SNR massimo è passato dai 26/36 di prima (lento/veloce) ai 47 di adesso. L’attenuazione è passata dai 49db di prima a 38db. Forse hanno accorciato di 1km la mia linea????

Boh, che dire.. non so cosa hanno fatto e quanto durerà ma spero bene!

Conclusione

E’ già una settimana che la linea va bene, meglio di quando credevo andasse bene, molto meglio di quando andava male. E’ un peccato che ci siano voluti 40 giorni e 8-9 segnalazioni di guasti duranti i quali hanno cercato di convincermi che era inutile lamentarsi della velocità della mia linea che andava così per via della distanza (giuro che casa mia non si è avvicinata alla centrale e nemmeno l’opposto!).

Chissà se l’apertura di vari thread su forum per segnalare il problema e questo blog che risultava ai primi posti su google cercando l’adsl di ngi ha in qualche modo avuto un peso nella soluzione del problema ma tutto è bene ciò che finisce bene!

Se state leggendo questo post ed avete problemi simili ricordatevi di rompere le palle: in italia sembra l’unico modo per essere ascoltati.

Nessun articolo simile

Dopo aver cercato un po’ mi sono accorto che non esiste un plugin che può monitorare il carico dei singoli processi in esecuzione su una macchina. Alcuni plugin permettono di creare un grafico specifico per un determinato processo ma nessuno lo fa in maniera aggregata per tutti i processi contemporaneamente.

Così, vista la semplicità con cui è possibile scrivere un plugin munin, ho deciso di crearne uno che facesse al caso mio.

Questo è il risultato che ho ottenuto con poco sforzo:

Uso della CPU per processo

Oltre al carico di CPU ho deciso di monitorare anche i minor-faults e i major-faults. I minor faults avvengono ogni qual volta un processo cerca di scrivere in una pagina di memoria protetta da scrittura, mentre i major faults avvengono quando questa operazione richiede anche una o più operazioni di I/O (e.g: swap). L’analisi dei minor/major faults può essere utile durante l’indagine di un problema di performance di un sistema.

Questo, ad esempio, è il grafico dei minor-faults corrispondente al precendete grafico di carico CPU per la stessa macchina:

Errori di pagina "minori" per processor

I plugin, da copiare nella cartella /etc/munin/plugins sono questi:
- processes_cpu
- processes_minorfaults
- processes_majorfaults

Dopo aver copiato i plugin, è necessario riavviare il munin-node:

sh# service munin-node restart

Possibili migliorie

Purtroppo i colori devo necessariamente lasciarli gestire a munin automaticamente.

Non ho idea di come si potrebbe fare a mettere in legenda solo quei processi che hanno usato almeno un 1% della CPU o funzionalità del genere.

Se lo stesso plugin viene installato in più macchine i processi vengono colorati diversamente per ogni macchina, rendendo di fatto poco intuitivo il confronto. Forse decidere il colore in base ad un hash calcolato dal nome del processo permettere stabilità ma potrebbe capitare che i processi più importanti abbiano poi un colore identico e siano indistinguibili.

Related posts:

1. Analizzare il traffico dei VirtualHost di Apache con Munin Prerequisiti Questo articolo prevede l’uso di Fedora Core 10 con...

Questo articolo prevede l’uso di Fedora Core 10 con Apache 2 installato e funzionante. Altre distribuzioni potrebbero richiedere la compilazione dei pacchetti che invece su FC10 sono già disponibili.

Installare CBand

Fortunatamente anche per il modulo cband esiste un pacchetto precompilato per FC10 e quindi l’installazione è molto rapida:

sh# yum install mod_cband

Installato il mod_cband aggiungiamo alla definizione di ogni VirtualHost che vogliamo monitorare la configurazione di cband:

<IfModule mod_cband.c>
CBandLimit 600G
CBandExceededURL http://www.google.com
CBandScoreboard /var/run/httpd/cband_scoreboard-#DOMINIO#
CBandPeriod 1W
</IfModule>

Da notare che ho impostato un limite di 600GB in 1 settimana, che nel mio caso corrisponde praticamente a non limitare, poichè il traffico è molto minore. E’ però necessario imporre un limite (seppur irraggiungibile) per far si che cband conteggi l’utilizzo di banda.

Fatto questo per ogni VH possiamo testare che la configurazione sia corretta, riavviare apache e vedere la pagina delle statistiche di cband:

sh# httpd -t
sh# service httpd restart

Aprendo http://localhost/cband-status vedremo una pagina simile a questa:

La pagina delle statistiche di cband

Impostare Classi in Cband

cband permette di definire fino a 3 classi di utenti in base all’IP. Con un po’ di lavoro possiamo quindi identificare i bot dei motori di ricerca, magari tenendo separato google che ci interessa più degli altri, e le classi di IP locali, per evitare che alcune macchine che effettuano richieste automatizzate possano inficiare le statistiche.

Queste sono le mie configurazioni messe in /etc/httpd/conf.d/mod_cband.conf

<CBandClass googlebot_class>
CBandClassDst 66.249.64/20
</CBandClass>

<CBandClass local_class>
CBandClassDst XXX.XXX.XXX.XXX
CBandClassDst 127.0.0.1
</CBandClass>

<CBandClass bots_class>
# Yanga
CBandClassDst 91.205.124.3/22
# Exabot
CBandClassDst 193.47.80.0/24
# Slurp
CBandClassDst 72.30.0.0/16
CBandClassDst 74.6.0.0/16
CBandClassDst 67.195.114.0/24
CBandClassDst 67.195.37.0/24
CBandClassDst 202.160.178.0/20
# Yandex
CBandClassDst 77.88.22.0/21
CBandClassDst 93.158.146.0/23
# Jyxobot
CBandClassDst 195.113.214.197
# DotBot
CBandClassDst 208.115.111.0/24
# libwww-perl
CBandClassDst 195.210.89.0/24
# MSN con referrer di ricerca
# CBandClassDst 65.55.104.0/21
# Twiceler
CBandClassDst 216.129.119.1/24
CBandClassDst 64.1.215.1/24
CBandClassDst 208.36.144.1/24
CBandClassDst 38.99.13.1/24
CBandClassDst 38.99.44.1/24
# AskJeeves
CBandClassDst 66.235.124.0/24
# majestic12
CBandClassDst 85.23.64.207
CBandClassDst 212.50.134.32
CBandClassDst 85.16.151.236
CBandClassDst 85.113.244.201
CBandClassDst 68.192.9.221
CBandClassDst 85.178.109.63
# Wikio Feed
CBandClassDst 84.55.184.91
# Turnitin
CBandClassDst 65.98.224.7
# MSN
# CBandClassDst 65.55.208.0/24
# CBandClassDst 65.55.51.0/24
CBandClassDst 65.55.0.0/16
CBandClassDst 219.142.53.0/24
# Gaisbot
CBandClassDst 122.147.76.64/28
CBandClassDst 210.66.69.128/26
CBandClassDst 219.87.182.128/27
CBandClassDst 220.228.152.64/27
</CBandClass>

In questo modo il calcolo del traffico avverrà separatamente per “classe”. Potremo conoscere il traffico degli “utenti normali” per differenza, sottraendo dal traffico totale le classi local_class, bots_class, googlebot_class.

Installare Munin

Munin è uno strumento di monitoring con un meccanismo di estendibilità a plugin estremamente semplice ed intuitivo (rispetto a MRTG) che permette di monitorare uno o più server.

Munin si divide infatti in due pacchetti: munin e munin-node.

Mentre munin-node è necessario in ogni server che intendiamo controllare il pacchetto munin serve solamente nella macchina che aggregherà le statistiche per creare dei grafici tramite il noto strumento rrdtool.

Su Fedora Core 10 installare munin è molto semplice:

sh# yum install munin munin-node

Una delle peculiarità di munin è l’autoconfigurazione: i plugin infatti possono verificare l’ambiente in cui sono installati per stabilire se sono “applicabili” all’ambiente o meno. Per verificare l’autoconfigurazione possiamo lanciare questo comando:

sh# munin-node-configure --shell

L’output di questo comando conterrà l’elenco dei comandi da impartire alla shell per installare i plugin che dichiarano la loro compatibilità.

Creare un plugin munin per mod_cband

A questo punto non ci resta che creare un plugin munin che legga la pagina /cband-status e permetta così a munin di visualizzare il grafico degli accessi diviso per vhost.

Questo è un esempio del plugin munin che richiede la pagina e ne estrae i dati:

#!/bin/sh

URL="http://localhost/cband-status?refresh=15&unit=K";
WGET=`which wget`;
WGET_FLAGS="-Yoff";

# Settigs required for autoconf
#%# family=manual
#%# capabilities=autoconf

if [ "$1" = "autoconf" ]; then
echo no
exit 0
fi

if [ "$1" = "config" ]; then

echo 'graph_title CBandwith Usage '
echo 'graph_args -l 0'
echo 'graph_category apache'
echo 'graph_info This graph shows per virtual host traffic from the cband module.'
echo 'graph_vlabel Kbytes per ${graph_period}'

wget -q $WGET_FLAGS "$URL" -O - | grep -A 3 http |grep "^<td .*http" |sed -e 's^.*http://\(.*\)".*^\1^' | while read site; do
metricname=$(echo $site | sed -e 's/\.//g')
#echo $metricname $site
echo $metricname'.label '$site
echo $metricname'.info Traffic generated on '$site'.'
echo $metricname'.min 0'
echo $metricname'.type DERIVE'
done;
exit 0
fi

if [ -x $WGET ]; then
SITES=$(wget -q $WGET_FLAGS "$URL" -O - | grep -A 3 http |grep "^<td.*http" |sed -e 's^.*http://\(.*\)".*^\1^')
$WGET -q $WGET_FLAGS "$URL" -O - | grep -A 3 http |grep "^<td.*\(color\|http\)" | while read v; do
echo -n $v | sed -e 's^.*http://\(.*\)".*^\1^' | sed -e 's/\.//g'
echo -n '.value '
read v;
echo $v | sed -e 's^.*\/\(.*\)KB.*^\1^'
done;
exit 0
fi

exit 0

E questo è il risultato:

Traffico generato da Google su ogni VHost

I plugin munin che ho creato sono molto spartani ma utili e controllano il traffico totale, quello di google, quello degli altri bots, e il traffico utente (il totale meno i robot e meno la classe locale).

Conclusioni

Il modulo cband, nonostante non più aggiornato dal 2006, non sembra pesare sulle performance e la stabilità di apache2 e dopo un mesetto di utilizzo ne sono soddisfatto.

Dovrei migliorare il plugin configurando meglio le impostazioni dei grafici (usare il min/max/avg, stili di linea differenti.

Troubleshooting

Se cband non vi funziona bene probabilmente si tratta di un problema di ordine di caricamento dei files nella /etc/httpd/conf.d . Questi files vengono caricati in ordine alfabetico, quindi se le definizioni dei virtualhost le avete qui assicuratevi che vengano il ordine alfabetico dopo al mod_cband.conf

Io, per convenzione, li chiamo vh-dominio.conf

Related posts:

1. Analizzare il carico dei processi con Munin Munin, come ho scritto ieri, è uno strumento di monitoring...

Lo spostamento di un sito/servizio web da un IP ad un altro può essere molto problematica. I grattacapi principali sono dovuti al tempo di propagazione del DNS, durante il quale i visitatori potrebbero approdare sia sul vecchio che sul nuovo IP in funzione di quale server DNS utilizzano e lo stato della cache.

Per ridurre al minimo questo problema è buona norma ridurre l’expire della cache di un dominio prima di un’operazione di trasloco di questo tipo, ma questa soluzione riduce solo il problema senza rimuoverlo.

Il problema fondamentale consiste nel fatto che a volte non possiamo permetterci che i due servizi su i 2 IP diversi ricevano richieste contemporaneamente perchè queste richieste potrebbero modificare lo stato di entrambi i server creando una divergenza non più sincronizzabile. Basta pensare ad un blog ed il fatto che alcuni utenti potrebbero commentare sul primo IP mentre altri sul secondo, con la conseguente perdita di dati che si avrebbe a transizione completata.

Una soluzione spesso adottata è quella di far rispondere il nuovo (www.dominio.com) sito ad una nuova URL tipo nuovo.dominio.com, sincronizzare il database, modificare la configurazione del webserver per far si che qualunque richiesta a www.dominio.com venga rediretta (302, temporary redirect) a nuovo.dominio.com e poi aggiornare il DNS. Questa soluzione però, oltre a non essere completamente trasparente per l’utente finale, potrebbe creare problemi nel caso in cui l’applicazione che dobbiamo spostare non sia indipendente dal nome. Potremmo infatti avere già dei cookie impostati per quel detterminato l’hostname o potremmo avere dei punti del codice che controllano quale sia l’hostname attuale.

Per questo motivo la mia soluzione preferita è quella di utilizzare un reverse proxy. In pratica si configura il sito nuovo, si sincronizza il db, poi si configura il vecchio non più per fare un redirect ma piuttosto per andare a chiedere la stessa pagina al sito nuovo e fornirla al navigatore.

Per fare questo con apache2 è sufficiente abilitare il mod_proxy in /etc/httpd/conf/httpd.conf togliendo il # dalle due righe:

LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_http_module modules/mod_proxy_http.so

ed aggiungere al virtualhost che stiamo spostando le seguenti istruzioni:

ProxyRequests Off
ProxyPreserveHost On
ProxyPass / http://[IP-NUOVO-SERVER]/

Con questa configurazione facciamo sì che le richieste fatte a quel sito vengano gestite non più dal server locale, ma piuttosto apache2 si preoccuperà di andarle a fare sull’[IP-NUOVO-SERVER]. ProxyPreserverHost ci serve così da poter mantenere l’Host nella richiesta e fare in modo che il server di destinazione riceva la richiesta come se l’avesse ricevuta dall’utente originale.

ProxyPass dice che tutte le pagine vengono “girate” al nuovo IP, ma potremmo anche decidere di fare questa operazione solo con alcune sottodirectory.

Esiste però ancora un problema legato a questa tecnica, e cioè che il nuovo server vedrà tutte le richieste venire dall’IP del vecchio server e non conoscerà più l’IP originale. Questo significa che i log avranno l’IP del “proxy” e che alcuni script potrebbero non funzionare bene.

Per questo viene d’aiuto un altro modulo apache chiamato mod_extract_forwarded che permette di estrarre l’IP presente nell’header X-Forwarded-For (aggiunto dal mod_proxy) e sostituirlo al remote address usato da apache.

Se il vostro nuovo server è una fedora core 10, come la mia, allora potete installare il modulo direttamente:

shell# yum install mod_extract_forwarded.i386

Il file di configurazione del modulo è in /etc/httpd/conf.d/mod_extract_forwarded.conf . E’ sufficiente aprirlo e modificare la riga MEFaccept inserendo l’elenco degli IP dei “proxy” fidati:

MEFaccept [IP-VECCHIO-SERVER]

E’ importante specificare questa opzione solo per gli IP dei proxy fidati perchè l’header X-Forwarded-For è un semplice header HTTP e di conseguenza è falsificabile molto semplicemente. Basti pensare che esiste una estensione Firefox che permette di impostare tale header a piacimento.

Ecco fatto, sia i log che tutte le applicazioni mostreranno l’IP originale e non quello del “proxy”.

Nessun articolo simile

VMware Server 2.0 - Interfaccia webAccess

VMware Server 2.0 - webAccess - Interfaccia macchina virtuale

La cosa interessante è che i servizi di gestione remota sono un servizio separato e quindi con Virtual Infrastructure Client 2.5 è possibile connettersi alla porta 8333 (in https) del server sul quale è installato VMware Server 2 e gestire tutti i parametri.

VMware Virtual Infrastructure Client 2.5

VIC 2.5 - Pagina macchina virtuale

L’unica limitazione è che con il VIC è possibile gestire solamente i formati di macchina virtuale fino al 4 mentre quelli fatti con l’interfaccia web (webAccess) sono in versione 7. Se volete mantenere la possibilità di disabilitare il webAccess, quindi, vi consiglio di creare le vostre macchine virtuali con il VI client.

Veniamo ora alla modifica del file /etc/rc.d/init.d/vmware
Dovrete trovare la funzione:

vmware_start_webAccess() {
  echo -n '   '"$webAccessServiceName"
  $watchdog -s webAccess -u 30 -q 5 "$webAccess $webAccessOpts start" > /dev/null 2>&1 &
}

e modificarla in

vmware_start_webAccess() {
  echo -n '   '"$webAccessServiceName"' DISABLED'
#  echo -n '   '"$webAccessServiceName"
#  $watchdog -s webAccess -u 30 -q 5 "$webAccess $webAccessOpts start" > /dev/null 2>&1 &
}

In questo modo al prossimo riavvio di vmware verrà comunque lanciato hostd (il servizio di gestione base) ma non il webAccess (l’applicativo basato su Java/Tomcat che si frega così tanta RAM).

Non si capisce perchè VMware abbia deciso di spezzare in script di avvio separati altri 3 servizi ma poi abbia deciso di consolidare hostd (management per le virtual machine) con webAccess (accesso web al management).

Chrissy propone una soluzione alternativa allo stesso problema.

Related posts:

1. Installare VMWare Server 2.0.1 su un RPS di OVH Cos’è OVH e cos’è un RPS OVH, importante società di...
2. Configurare la rete per VMware server e gli IP Failover in un dedicato OVH Prerequisiti Innanzitutto dovete aver configurato un kernel modulare e installato...

Configurazione standard DRBD

Premessa

DRBD (Distributed Replicated Block Device) è una sorta di disco virtuale che gestice un RAID 1 via rete. In pratica due dischi installati su due macchine fisiche diverse possono essere visti come unico disco. DRBD è uno dei mattoni fondamentali per la gestione di un cluster HA (High Availability) low cost.

Requisiti

Esistono gli RPM di DRBD già fatti per Centos e si possono usare anche con la Fedora, però funzionano solo con i kernel ufficiali delle rispettive distribuzioni, quindi dovremo crearci il nostro pacchetto.

Innanzitutto dovete assicurarvi di avere installato un kernel che supporta i moduli e che supporta la funzionalità “Connector”.

Inoltre è consigliabile che abbiate riservato una partizione, identica sulle due macchine che vorrete mantenere sincronizzate, da utilizzare con DRBD.
Se non ne avete una potrete comunque provare creando un loop device (questo crea un loop device da 10GB):

shell# dd if=/dev/zero of=/home/drbdloop bs=1024 count=10485760
shell# losetup /dev/loop0 /home/drbdloop

In questo modo avrete un device (/dev/loop0) da utilizzare come disco per DRBD.

Compilazione di DRBD

shell# cd /usr/src
shell# wget http://oss.linbit.com/drbd/8.3/drbd-8.3.1.tar.gz
shell# tar -zxf drbd-8.3.1.tar.gz
shell# cd drbd-8.3.1
shell# make rpm

Nel mio caso mi è stato dato un errore perchè nel mio sistema mancava flex.

errore: Compilazione dipendenze fallita:
flex necessita di drbd-8.3.1-3.i386

In realtà l’errore italiano è tradotto male. Il problema è l’esatto opposto. E’ sufficiente installare flex e ripetere il make:

shell# yum install flex
Installato:
  flex.i386 0:2.5.35-2.fc9
shell# make rpm
[ COMPILAZIONE ]
+ exit 0
You have now:
-rw-r--r-- 1 root root 185530  3 apr 11:23 dist/RPMS/i386/drbd-8.3.1-3.i386.rpm
-rw-r--r-- 1 root root 304874  3 apr 11:23 dist/RPMS/i386/drbd-debuginfo-8.3.1-3.i386.rpm
-rw-r--r-- 1 root root 154010  3 apr 11:23 dist/RPMS/i386/drbd-km-2.6.28.4_custom_std_ipv4_32_mod-8.3.1-3.i386.rpm

A questo punto sarà sufficiente installare drbd (i tools) e drbd-km (il modulo del kernel).

Installazione di DRBD

shell# rpm -Uvh --force dist/RPMS/i386/drbd-8.3.1-3.i386.rpm dist/RPMS/i386/drbd-km-2.6.28.4_custom_std_ipv4_32_mod-8.3.1-3.i386.rpm
errore: Dipendenze fallite:
        kernel necessita di drbd-km-2.6.28.4_custom_std_ipv4_32_mod-8.3.1-3.i386

La distribuzione di fedora core 9 fatta da OVH non include un pacchetto kernel, ma noi abbiamo installato il kernel manualmente e quindi forziamo l’installazione.

shell# rpm -Uvh --nodeps dist/RPMS/i386/drbd-8.3.1-3.i386.rpm dist/RPMS/i386/drbd-km-2.6.28.4_custom_std_ipv4_32_mod-8.3.1-3.i386.rpm
Preparazione in corso...    ########################################### [100%]
   1:drbd                   ########################################### [ 50%]
   2:drbd-km-2.6.28.4_custom########################################### [100%]
shell#

Ogni volta che cambierete il kernel dovrete ripetere questa procedura ed installare il nuovo modulo del kernel (ne possono coesistere più di uno).

Failover di un sistema con DRBD

Configurazione DRBD

D’ora in poi ipotizzerò che le due macchine siano rXXXX1.ovh.net e rXXXX2.ovh.net, che l’IP delle due macchine sia rispettivamente 87.98.XXX.101 e 87.98.XXX.102 e che per entrambe le macchine la partizione di cui tenere il mirror sia /dev/sda5.

Innanzitutto dovremo configurare la risorsa (che chiamo “r0″ ma alla quale potrete assegnare il nome che preferite) su /etc/mrtg.conf

resource r0 {
  protocol C;
  startup { degr-wfc-timeout 120; }
  syncer { rate 3M; al-extents 257; }
  on rXXXX1.ovh.net {
    device /dev/drbd0;
    disk /dev/sda5;
    address 87.98.XXX.101:7789;
    meta-disk internal;
  }
  on rXXXX2.ovh.net {
    device /dev/drbd0;
    disk /dev/sda5;
    address 87.98.XXX.102:7789;
    meta-disk internal;
  }
}

Una volta configurato possiamo preparare il disco con i metadati di DRBD ed attivare la risorsa:

shell# drbdadm create-md r0
shell# drbdadm up r0

Fate la stessa cosa sul secondo server e poi, sul server che volete sia il primario (quello che potrà montare la partizione) fate:

shell# drbdadm -- -o primary r0

Ora /dev/drbd0 è un dispositivo a blocchi (disco virtuale) valido e possiamo procedere nella formattazione:

shell# mkfs.ext3 /dev/drbd0

A questo punto potrete montare il disco ed utilizzarlo

shell# mkdir /mnt/discoha
shell# mount /dev/drbd0 /mnt/discoha

Se non volete rischiare di perdere tutti i dati per un comando errato è d’obbligo la lettura del manuale, per una buona comprensione dello stato di connessione, dello stato dei dischi e dello stato della sincronizzazione.

Se vi interessano configurazioni master-master in cui entrambi gli host possono usare contemporaneamente il disco allora avrete bisogno di una filesystem distribuita come OCFS2 o GFS: leggete l’articolo di GuiGui che riporto in fondo all’articolo per un esempio.

Riferimenti

Dal manuale – Building a DRBD RPM package
Articolo di GuiGui -
Mise en oeuvre d’un système de fichier distribué et accès concurrents en SAN avec DRBD, ISCSI ,OCFS2 et DM-Multipath

Related posts:

1. Installare VMWare Server 2.0.1 su un RPS di OVH Cos’è OVH e cos’è un RPS OVH, importante società di...
2. Installare un kernel modulare su un RPS di OVH Gli RPS (Real Private Server) di OVH sono server “reali”...

shell# service vmware start
VMware Server is installed, but it has not been (correctly) configured
for the running kernel. To (re-)configure it, invoke the
following command: /usr/bin/vmware-config.pl.

Se usate OVH e vi capita di riavviare con un kernel differente (ad esempio via netboot) per fare qualunque cosa e poi tornare al kernel su hd con il quale vmware dovrebbe funzionare ogni volta vmware vi farà questo scherzo perchè quando partite con il netboot non riesce a caricare i propri moduli e si segna che deve essere riconfigurato.

La soluzione è piuttosto semplice: prima di riavviare la macchina con il kernel corretto ricordatevi di cancellare il file “not_configured” che ha creato appena partito con il kernel non modulare:

shell# rm -f /etc/vmware/not_configured

In questo modo vi risparmierete di rilanciare la configurazione e la conseguente ricompilazione ogni volta che fate un netboot!

Se vi dimenticate di farlo prima di riavviare potete farlo anche quando il sistema è già riavviato, ma dopo dovrete avviare vmware manualmente (service vmware start).

Related posts:

1. Installare VMWare Server 2.0.1 su un RPS di OVH Cos’è OVH e cos’è un RPS OVH, importante società di...
2. Configurare la rete per VMware server e gli IP Failover in un dedicato OVH Prerequisiti Innanzitutto dovete aver configurato un kernel modulare e installato...
3. Liberare 240MB di RAM disabilitando la console web di VMware Server 2 La versione 2.0 di VMware Server ha introdotto una nuova...