L'acquisizione di nuovo hardware, a quanto pare supportato solo da kernel recenti, mi ha costretto ad affrontare uno dei peggiori incubi del sistemista: l'aggiornamento di kernel.  Non è un vero e proprio incubo, perché in verità modernamente non è niente di complesso o faticoso, essendo già disponibili versioni pacchettizzate di versioni recenti; ho affrontato in passato in grandi realtà questo tipo di attività, ma sempre in ambiti dove le applicazioni erano scarsamente dipendenti dal sistema operativo (applicazioni Java, database Oracle, web server generici o file server). Qui da me la questione è differente e possiamo individuare almeno tre punti di attenzione:

• il centralino Asterisk, con una scheda TDM e un telefono Cisco supportato tramite modulo aggiuntivo (chan_sccp)
• una istanza di VMware Server 2, ovviamente strettamente legata al kernel
• la componente di domotica legata al riconoscimento di alcuni device USB

non voglio soffermarmi su questi aspetti perché non è il tema dell'articolo, ma basti dire che per quanto riguarda Asterisk è stato necessario un aggiornamento da 1.4 a 1.6, per poter supportare il cambio di driver della scheda TDM da zaptel a dahdi; questo ha richiesto a sua volta un aggiornamento del driver per i telefoni Cisco (per fortuna il suo sviluppo è ripreso e sono quindi disponibili per la compilazione) e il codec g729. VMware Server attualmente è del tutto incompatibile con kernel recenti ma per fortuna qualcuno ha sviluppato una patch (aggiuntiva alla patch che già uso per il supporto delle VLAN) per estenderne la compatibilità. La parte domotica per fortuna non ha opposto resistenza.

Terminati i test di non regressione da 2.6.26 (Debian 5, Lenny) a 2.6.32 (Debian 6, Squeeze) durati quasi una intera giornata mi sono rilassato, soddisfatto di aver superato l'ostacolo. Masterizzo qualcosa, avvio nuovamente tutte le mie Virtual Machine... ma vedo che il mio piccolo server fatica a rispondermi. Un top mi comunica che l'estrema lentezza è dovuta ad un elevato i/o wait, insomma siamo tutti in attesa di dati provenienti probabilmente dai dischi.

Se c'è qualcosa che ho cambiato negli ultimi anni è il sistema di gestione dei dischi, passando dal RAID software del vecchio assemblatone al nuovo controller E200 del nuovo ML110G5, questo per vivere più sereno e avere finalmente un vero RAID hardware. Sembra però che si siano materializzati su di esso degli incudini che lo rendono particolarmente lento... cosa fare?

Una volta affrontato l'aggiornamento del kernel e di una marea di librerie e software, tornare indietro è una idea del tutto velleitaria, perché alcuni interventi sono notoriamente irreversibili, primo tra tutti il patching di VMware, per non parlare dell'avvicendamento di alcuni driver; bisogna quindi mantenere la posizione e contrastare l'avanzata dei problemi. Cercando in rete emerge che i problemi di performance si verificano a partire dal kernel 2.6.29, insomma per qualcuno il 2.6.28 viaggia a circa 90MB/s ed il 2.6.29 e successivi a circa 13MB/s; non mi sento di confermare queste stime ma sicuramente il server se la passa male, con un carico che sfiora i 20. Dopo varie ricerche e alcuni tentativi posso dirvi che le prestazioni tornano nella norma con i seguenti settaggi, che possono essere riportati in /etc/rc.local:

echo 64 >/sys/block/cciss\!c0d0/queue/read_ahead_kb
echo 0  >/sys/class/block/cciss\!c0d0/queue/iosched/low_latency
echo deadline  >/sys/class/block/cciss\!c0d0/queue/scheduler

in pratica in buona parte dei casi si riportano alcune variabili ai valori di default delle precedenti versioni di kernel, in particolare read_ahead_kb, nel 2.6.29+ di default a128K, e lo scheduler, che in passato era deadline ed oggi sarebbe cfq. Ora il server è più scattante e in attesa di novità questa risulta essere una buona soluzione, valida sia per Debian 6 ma immagino anche per RedHat 6 e derivate.

Da qualche mese ospito in casa un Roomba 520, il moderno modello base di questa famiglia di orsetti lavatori motorizzati,  più che sufficiente non avendo esigenze di programmazione (che suggerirebbero il 555 o 581) o animali a pelo lungo (modello 563). Solo qualche giorno fa alla FNAC sono venuto a sapere che è disponibile un telecomando ad infrarosso per la gestione dell'oggetto; niente di speciale, essendo solo possibile avviare/fermare la pulizia e guidare il Roomba. Non avendo però trovato indicazioni sul prezzo di vendita ho lasciato perdere.

Incuriosito da questa nuova possibilità ho fatto una veloce indagine ed ho scoperto che il telecomando multifunzione Logitech Harmony ha un profilo di configurazione anche per il Roomba, anche se è necessario applicare un piccolo accorgimento per la buona riuscita della configurazione.

Leggi tutto...

Da qualche giorno, sarà capitato a molti, Pidgin si lamenta sonoramente di non potersi collegare ad MSN tramite il server omega.contacts.msn.com a causa di un errore di certificato. Pare che Microsoft abbia infatti modificato il certificato del server, speriamo consciamente e non a causa di qualche attacco, rendendo difficoltoso l'accesso a chi quel certificato già l'aveva memorizzato in altro formato. Quale cura per farlo smettere di starnazzare?

Leggi tutto...

Ci sono sfide che è meglio non vincere, ma anche sfide che sono ridicole per la differente dimensione dei partecipanti. Una di queste sfide è la continuità di servizio, cioè per semplificare il rapporto tra la disponibilità e indisponibilità di un dato servizio, in questo caso la posta elettronica.L'utente medio ha una percezione abbastanza semplice della questione: "funziona sempre", oppure "non va mai"; l'utente infatti non ha mezze misure, anzi non ha proprio misure e tende ad estremizzare. L'utente tende inoltre ad avere una memoria storica che nei casi più rari, e con rari intendo precisi e meticolosi, arriva a ricordare cosa ha mangiato due sere prima.

Il sistemista invece ha un libro nero dove appunta qualsiasi problema, che si tratti del sistema di posta che non va o del tostapane che ha non reso croccanti le fette di pane. Se poi non ha il tostapane ma ne vorrebbe uno, consulta tutti i giorni i siti specializzati e stila una classifica. Dove appunta questa classifica? No, non nel libro nero, ma in quello rosso.

Tornando a noi uno dei servizi a cui l'utente medio è più sensibile è la posta elettronica, ancora di più nella fascia oraria lavorativa, si perché durante quella extralavorativa o non gli interessa o comunque a non andare è il Blackberry,  l'IPhone o il palmare di turno, trappole di cui è meglio non fidarsi. Se succede fuori dall'orario lavorativo quasi mai l'utente imputa il problema al fornitore, ma gridando al complotto pensa male del proprio operatore telefonico o di quella merda di cellulare, guardando in vetrina il modello che si vorrebbe comprare.

Sono utente Google Mail, più che altro per usufruire e analizzare i loro servizi integrati e da qualche tempo anche utente indiretto dei servizi di Microsoft Online, per gli amici BPOS. Una ammucchiata di server Exchange sparsi per il globo e configurati da chi quel software del demonio l'ha fatto, quindi di indubbia affidabilità. Senza scendere nei particolari diciamo che sono talmente affidabili che Microsoft, infischiandosene delle regole della grande rete, ha deliberatamente omesso qualsiasi server di backup.

Tutto il panegirico per dire che Range, il mio provider di fiducia, su base annuale è rimasta indisponibile per un'ora. Un'ora su 365 giorni, un'ora su  8760 ore in un anno, un totale del 99,989% di uptime, un'ora di indisponibilità il 30 di dicembre mi pare, alle 19, dopo che il 27 era esploso il primo server del cluster di backend ed il 30, infastidito dalla noia, ha deciso di esplodere anche il secondario. Un'ora in cui è stata avviata la procedura di restore di tutto e si è tornati online. Non si tratta di una percentuale di disponibilità altissima, ci sono aziende che pretendono anche il 99,999% ad esempio, detto anche il five nines.

Ora veniamo alla concorrenza, anche se chiamarla concorrenza è inesatto. Range non è raffrontabile con BPOS o Google per numero di clienti è ovvio, quindi anche di carico; ma è anche vero il contrario, Google o Microsoft non sono raffrontabili con Range per quantità di risorse, intese come server, persone e soldi, messi a disposizione allo scopo. 

La concorrenza, su base annua, ha totalizzato ben più di un'ora di disservizio; tutti ricordiamo il blocco globale di Google per un paio d'ore nella sola fine anno del 2009 e BPOS da quando la conosco ha realizzato almeno 40 minuti filati di buio, a cui si aggiungono notizie (intese come articoli che riportano con precisione il disservizio) di un down ancora più prolungato tre mesi fa. Anzi a dire il vero mentre Google si è più o meno stabilizzata, gli analisti dicono che da quando Microsoft ha presentato il servizio i segni di cedimento si sono fatti abbastanza regolari.

Come detto le realtà non sono raffrontabili e sicuramente le due società impareranno dai propri errori, ma ad oggi il loro grado di affidabilità è inferiore ad un medio provider italiano, alla faccia del nome e delle rassicurazioni commerciali.