22/01/2015

Benvenuto Banana PI

Mi rendo conto solo ora che è passato quasi un secolo da quando presentai su questo blog il mio leggendario server domestico basato su Via Epia.

Da allora la mia attenzione in questo campo è aumentata in modo esponenziale e dopo elocubrazioni varie ho varcato la soglia del mondo ARM con Raspberry PI.
Sia chiaro, considero Raspberry PI un progetto STUPENDO e RIUSCITISSIMO, sia dal punto di vista tecnico che di comunicazione, tant’è che ne ho comprati ben due e l’ultimo di questi mi sta fedelmente servendo da parecchio tempo.

Ciò nonostante le limitazioni di Raspberry PI sono palesi, tecnicamente e anche eticamente (etica informatica? Già, perchè no?).
Tecnicamente parlando il SOC di cui è dotato è parecchio datato e poco potente, ottimo per tantissime attività ma dalle performance scarse in molti campi (ad esempio come nas o backup repository, come webserver o application server).
Inoltre bisogna ammettere che il sottosistema di I/O è progettato piuttosto male, tant’è che una delle più frequenti cause di problemi è proprio il controller USB su cui ricadono sia la scheda di rete (a 100 Mbps) che le porte USB, unica connessione disponibile per storage capiente e alternativo alla scheda SD.
Io stesso sono stato costretto a pensionare il mio primo esemplare a causa del controller USB che una volta posto sotto stress disconnetteva il device USB corrispondente al disco esterno da 2.5″ dove risiedono i miei file.
Dal punto di vista etico invece non posso fare a meno di notare la stridente contraddizione di un progetto che ha fatto della filosofia Open Source la sua bandiera, ma che di fatto è fortemente “closed”, tant’è che ad oggi non sono stati resi pubblici gli schemi dell’hardware stesso.

Visto il successo di questo progetto è bastato poco perchè nascessero molte iniziative simili, alcune con tutti i requisiti tecnici per surclassare Raspberry PI (una molto interessante ma dal costo esageratamente elevato è Cubietruck di cui avevo già parlato).
Per fortuna alcune di queste si sono consolidate, hanno creato una discreta comunità di utenti e, cosa che non guasta mai, hanno proposto le loro soluzioni a prezzi accessibili; tra queste le principali sono Banana PI e le board Olimex (delle quali la più interessante ad oggi è la Lime2).

Tecnicamente si tratta di due progetti molto simili, basati entrambi su SOC ARM Cortex-A7 dual-core (Allwinner A20), 1GB di ram, controller SATA, scheda di rete gigabit ethernet e prezzo tutto sommato allineato (circa 45 euro); rispetto a Raspberry PI la potenza computazionale e le performance di I/O sono sbalorditive, e nonostante questo l’assorbimento è persino più basso.
Anche eticamente le due schede sono simili, di entrambi infatti sono disponibili i sorgenti e tutta la documentazione.

Come è intuibile dal titolo ho scelto Banana PI, ero molto incuriosito dal prodotto Olimex ma la disponibilità da Amazon mi ha fatto propendere per il concorrente; oggi poi mi è pure stato recapitato il case in plexiglass con relativo cavo SATA (con alimentazione integrata), per cui quale migliore occasione per immortalare questo magico scatolino?

A breve mi aspetta una colossale migrazione (lavorativa), appena avrò finito e sarò riuscito a tirare un po’ il fiato procederò con la migrazione (domestica) del muletto al nuovo Bananone :)

bananapi03

22/10/2014

Ubiquiti uber alles

Come risollevare le sorti di una giornata di merda:

  1. effettuare upgrade del proprio Ubiquiti Unifi controller che gira su un minuscolo Raspberry PI
  2. ripristinare il backup della vecchia istanza di Unifi controller che gira sempre sul minuscolo Raspberry PI
  3. deployare l’ultima versione di firmware sul proprio access point Ubiquiti AP LR
  4. abilitare il tanto agognato protocollo SNMP
  5. osservare che snmpwalk si spazzola i mib SNMP del proprio access point

Dunque vediamo…

1, 2, 3 –> DONE

unifi

4, 5 –> DONE

unifisnmp

Basta così poco per farmi felice… :)

14/08/2014

Ubiquiti Unifi AP LR

Qualche mese fa ha suonato alla mia porta il corriere di Amazon (che ormai comincerà ad odiarmi vista la quantità di ordini che faccio sul sito…) per consegnare un pacco che attendevo con una certa trepidazione, il nuovo access point Ubiquiti Unifi AP LR.

Ho già avuto una precedente esperienza con i prodotti Ubiquiti Unifi (modello AP PRO) che mi ha lasciato una impressione estremamente positiva, dato che negli ultimi tempi il mio precedente access point Tp-Link TL-WA901ND V2 ha mostrato performance pietose ho preferito andare sul sicuro e puntare su un prodotto consolidato e di sicura affidabilità.

L’AP è decisamente compatto e dalle forme eleganti e, cosa non banale e sicuramente comoda, può essere alimentato mediante PoE (Power over Ethernet), ovvero potete alimentarlo direttamente dal cavo ethernet utilizzando un apposito adattatore fornito in bundle (=no foresta di mangrovie di cavi).
Il dispositivo è pensato prevalentemente per utilizzo in ambito soho o comunque professionale, pertanto è dotato anche di apposita mascherina per il montaggio a soffitto; nel mio caso ho scartato questa soluzione, ma avendola provata in ufficio devo confessare che è estremamente funzionale e comoda, soprattutto se utilizzate un soffitto a pannelli (sarebbe fantastico se Ubiquiti fornisse anche pannelli per il montaggio a rack dei dongle di alimentazione PoE).

unifi

Unifi AP LR con natura mortissima e conchiglie…

Come per tutti gli altri modelli della serie (oltre che per i router ethernet Ubiquiti) l’access point non ha una interfaccia di amministrazione stand-alone (al massimo è possibile connettersi in ssh al dispositivo) e per essere configurato è necessario installare (su un comune pc o server) il software di amministrazione UniFi Controller, i cui requisiti sono tali da poter essere utilizzato su qualsiasi sistema operativo (si tratta di una applicazione java distribuita tramite archivio .jar), persino Raspberry PI.
Il software è estremamente semplice da usare e permette di amministrare da un singolo dispositivo fino a una intera batteria di access point e router dalla stessa interfaccia, di fatto permette di godere dei vantaggi di una architettura enterprise con controller dedicato senza doversi svenare con prodotti concorrenti (Cisco Aironet e SonicWall in primis).

Configurazione radio con mappa per verificare la sovrapposizione della copertura

Configurazione radio con mappa per verificare la sovrapposizione della copertura

 

Statistiche grafiche client, configurazione wifi, tagging VLAN e selezione profilo cifratura

Statistiche grafiche client, configurazione wifi, tagging VLAN e selezione profilo cifratura

 

Elenco client e pagina principale per abilitazione guest client

Elenco client e pagina principale per abilitazione guest client

 

Settings, notifiche, logging, rogue ap detection

Settings, notifiche, logging, rogue ap detection

Dal punto di vista prettamente operativo il passaggio dal mio vecchio modello TP-Link a questo nuovo Unifi ha risolto completamente i problemi di copertura e banda che sperimentavo col vecchio AP.
Nonostante l’etichetta LR (Long Range) la copertura del segnale è molto simile al mio precedente modello, a differenza di prima però anche in condizioni di segnale non eccellente la banda passante è più che sufficiente per qualsiasi utilizzo abbia sperimentato fin’ora.
Per farvi un esempio, in precedenza in certi punti rilevavo una copertura ridotta e una banda passante talmente ridicola da non riuscire a sostenere nemmeno lo streaming di un filmato Youtube a bassa risoluzione, ora riesco tranquillamente a visualizzare senza interruzioni filmati a 720p (ovviamente i test sono stati effettuati senza altro traffico wan e verificando le performance della connessione stessa a prescindere dalla copertura wifi).

Non è mia intenzione effettuare un test esaustivo (anche perchè al momento non dispongo nemmeno di un client con interfaccia tale da permettere di sfruttare appieno il channel bonding sui 2.4GHz), ma giusto per avere un’idea della resa ho provato a misurare un trasferimento via share di rete (cifs) ottenendo questi risultati in ricezione…

wifi.receive

…e in trasmissione

wifi.transmit

Risultati alquanto buoni per un dispositivo di questa fascia di mercato, ancora di più considerando il fatto che per il test ho dovuto utilizzare un client con interfaccia limitata a 240Mbps, quindi con una differenza del 20% si potrebbero ipotizzare quasi 80Mbps in upstream e quasi 90Mbps in downstream, non male davvero…

In definitiva non posso che essere entusiasta di questo access point, performance e copertura ottime per un dispositivo 802.11n 2.4GHz, esteticamente sobrio e piacevole, molto versatile e dotato di un software di gestione davvero completo, a questo aggiungete il fatto che c’è una comunità molto attiva e il dispositivo è ampiamente personalizzabile (OS BusyBox).
Unico neo di questo Ubiquiti AP LR è l’interfaccia ethernet a 100Mbps, effettuando test simili sul fratello maggiore AP Pro (che monta interfaccia gigabit ethernet)  ho riscontrato performance di poco superiori ma comunque simili.

In rapporto al prezzo e per questo genere di dispositivi (802.11n 2,4GHz) credo sia una delle migliori soluzioni disponibili sul mercato.

14/07/2014

OVH VPS Classic

Eccomi qui a distanza di un anno esatto ad affrontare l’ennesima migrazione del blog (che ormai somiglia sempre più a un ambiente di test per provider).

Dopo aver aver provato l’ottimo servizio di hosting di Siteground ho mio malgrado deciso di cambiare aria, non certo per la qualità del servizio (sempre ottima), ma per una pura questione di costi; al termine dell’anno promozionale l’hosting condiviso base di Siteground lievita a quasi 100 $ l’anno, decisamente troppo per il mio target.

A questo punto il dubbio amletico: hosting o vps?
OVH ha deciso di togliermi ogni dubbio in merito con una offerta che francamente ha del miracoloso, ovvero VPS Classic:

  • 1 CPU Opteron 4284 3GHz
  • 1 GB di ram
  • 10 GB di storage
  • banda e traffico a carrettate

…il tutto alla modica cifra di 2,43 € al mese iva inclusa.

Il servizio di primo acchito sembra essere ottimo, ordine e pagamenti semplici e immediati, tempo 5 minuti dal pagamento e sarete già connessi in ssh al vps.

ovh-vps1

L’interfaccia di amministrazione è pulita e molto funzionale, la schermata principale mostra le risorse della macchina, gli ip, lo stato dei servizi in ascolto (http, https, ssh, dns, smtp e raggiungibilità via ping) e poco altro.
Accedendo ai menù avanzati è possibile verificare l’andamento delle principali risorse in modo più dettagliato, riavviare, modificare la password di root (il che causa un riavvio del vps), modificare il contratto o rinnovarlo, e reinstallare il vps scegliendo tra diverse distribuzioni (Debian 6 e 7, CentOS 6, Ubuntu 13.10 e 14.04) o setup che comprendono alcuni dei cms più diffusi o pannelli di amministrazione.

Ovviamente non manca un comodo KVM che permette di accedere alla console del vps, giusto nel caso abbiate pasticciato un po’ con la rete e iptables.

OVH - VPS

Le performance sono… eh no, queste le vedremo prossimamente, diciamo che per ora sono più che soddisfatto :D

07/05/2014

Cache write-through vs write-back

Una delle cose che spesso vengono sottovalutate nella configurazione dello storage in RAID con parità (tipicamente RAID5) è l’importanza della batteria tampone e conseguentemente la configurazione della cache write-back anzichè write-through.

Molti pensano che la batteria tampone sia una sorta di gadget, bello e soprattutto costoso, perchè diciamocela tutta, queste miserabili e banalissime batterie al litio sono care come il fuoco, e se esistesse una divinità della giustizia vedremmo fulmini cadere h24 sulle sedi di Adaptec, LSI, IBM, Dell, HP e tutte le altre società coinvolte in questo sanguionosissimo mercato…
Purtroppo l’utente medio (almeno questa è la mia esperienza frequentando varie realtà aziendali) è portato a pensare “Massì, è già tanto se abbiamo un controller raid hardware, noi non siamo così enterprise da aver persino bisogno della batteria…”. oppure “Ok, cosa cambiera mai con la batteria o senza… i dati sono comunque al sicuro”.

Tralasciamo i commenti su questa sensazione di finta sicurezza (“shit happens”, e non è questione di se, ma di quando…), il fatto è che le batterie tampone servono, e non solo per permettere la corretta esecuzioni delle transazioni di I/O, ma anche per una pura e semplice questione legata alle performance degli array con parità, più nello specifico le politiche di utilizzo della cache nell’esecuzioni delle attività di scrittura.
Non smetterò mai di lottare contro gli array RAID5 e RAID6, uno dei motivi per i quali osteggio questo genere di configurazione è la cosidetta write penalty, ovvero il sovraccarico di IOPS dovuto calcolo e salvataggio della parità durante ciascuna attività di scrittura; per tamponare questo handicap i controller dotati di batteria tampone utilizzano la cache del controller in modalità write-back (ovvero asincrona), in caso contrario utilizzano la più sicura modalità write-through (sincrona), per una spiegazione più esaustiva rimando a questa pagina di Wikipedia.

Se pensate che questa differenza possa essere marginale date un’occhiata al grafico che segue, queste sono le prestazioni di una lun su san IBM DS4300 con array raid5 composto da tre dischi SCSI Ultra320 da 10.000 rpm durante una banale import di uno schema Oracle 9 su GNU/Linux iniziata alle ore 01:00AM (non le 13:00).
San preistorica, server ancora più antiquato, storage malridotto, sistema operativo antidiluviano (RedHat Enterprise 3), tutte ottime ragioni per giustificare delle performance così basse, guardate però la differenza tra le prestazioni antecedenti alle ore 13:00 (batteria nuova in carica e cache write-through attiva) e dopo le ore 13:00 (batteria online e cache write-back)… non ho altro da aggiungere.

io-cache

« Post precedenti | Post successivi »