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

02/03/2014

Server assemblato

Frequentando vari forum e newsgroup che trattano tematiche sistemistiche mi capita di incappare piuttosto frequentemente in richieste d’aiuto da parte di persone che lavorano per piccole aziende e che vogliono/devono sostituire un server aziendale.
Generalmente in questi casi le esigenze sono piuttosto modeste, e i servizi ricadono quasi sempre nei classici DNS, DHCP, piccolo dominio Active Directory, gestionali vari (Zucchetti&C per capirci), e spesso gli interessati si presentano chiedendo consigli sui componenti con cui assemblare la macchina in questione.

Dato che:

  1. queste casistiche sono molto frequenti
  2. sono sinceramente interessato all’argomento
  3. non mi va di ripetermi tutte le volte

ho deciso di scrivere questo post in modo da chiarire una volta per tutte perchè secondo me la soluzione del server assemblato è una pessima idea.

COSTI
Sfatiamo subito un mito, un server “brandizzato” non costa più di un server assemblato, potrà sembrare strano ma è così.
In realtà la cosa è facilmente intuibile anche da chi non ha familiarità con il mondo IT, a parità di componentistica come può un privato (o una azienda) scucire un prezzo migliore su un singolo pezzo rispetto a un colosso come IBM, Dell o HP che effettuano ordini per migliaia o milioni di pezzi?
Qualcuno a questo punto potrà affermare che un pc basato su Intel Core i5 fa lo stesso lavoro del server IBM basato su cpu Intel Xeon, benissimo, ma allora perchè non comprare un pc Lenovo o HP o Dell anzichè un server?
Mi spiego, che senso ha paragonare i costi di un server rispetto ad un semplice PC? Questo ci porta al punto 2

COMPONENTISTICA
Inutile che ci giriamo attorno, un server NON E’ UN PC PIU’ POTENTE.
L’architettura è la stessa, la componentistica potrà sembrare simile, ma non sono la stessa cosa, un server è una macchina che ha come obbiettivo primario l’affidabilità e la stabilità, una workstation ha altri obbiettivi.
Un server è ben più di un case con dentro una mainboard con installata una CPU, un po’ di RAM, un controller per lo storage e qualche disco; un server è una macchina con componentistica custom (non per complicare la vita, ma anzi per semplificarla, sostituire una mainboard svitando una vite e tirando una leva è ben diverso dello smontare ogni componente come su un pc), con componenti di monitoraggio specifiche (BMC) che rispettano standard ufficiali (IPMI), con interfacce di controllo remoto complesse (interfacce di Lights-Out management), con componenti ridondate per garantire la continuità di servizio, e spesso con tecnologie e soluzioni proprietarie molto interessanti  (pensiamo ad esempio alla sostituzione della ram a caldo, piuttosto che a tecnologie di aggregazione delle risorse tipo IBM X6 o di virtualizzazione hw LPAR)

QUALITA’ COSTRUTTIVA
A me piace parecchio assemblare i miei pc, è un’attività che mi rilassa e mi diverte, e le poche volte in cui capita impiego tantissimo tempo per curare ogni minimo dettaglio, fascettare ogni cavo, curare anche i dettagli estetici. Ciò nonostante sfido chiunque (anche il più assatanato cultore delle fascette plastiche) a raggiungere la qualità costruittiva e l’ingegnerizzazione interna di un server “brandizzato” o anche di un semplice pc.
Chiunque abbia guardato dentro una macchina Lenovo, IBM, Dell o HP può confermarlo, la precisione nell’assemblaggio e la pulizia di una soluzione ufficiale di questi produttori batte 6:0 6:0 6:0 anche l’assemblatore più appassionato, merito anche del fatto che queste società possono permettersi di utilizzare componentistica customizzata, e non parlo solo di mainboard o dissipatori, mi riferisco anche solo alle cose più banali come un semplice connettore di alimentazione con una forma particolare che il privato (o azienda) non potrebbe mai procurarsi.

Qualcuno a questo punto ribatterà sul fatto che un appassionato mediamente va a scegliere componenti più blasonate, mentre un server “brandizzato” è una sorta di black box dove non è dato da sapere quali componenti specifiche vengono usate (ad esempio che latenza ha la ram, chi è il produttore degli hard disk, che tipo di condensatori sono stati utilizzati sulla mainboard etc etc etc…), questo ci porta al punto successivo.

PEZZI DI RICAMBIO
E’ vero, su un server “brandizzato” l’utente non ha il pieno controllo di ogni dettaglio, si può scegliere il modello di CPU, la quantità di RAM e in certi casi la sua frequenza, si può scegliere il tipo di storage, il numero e il taglio dei dischi, il tipo di controller, il numero degli alimentatori, ma molti dettagli non sono selezionabili, il perchè è talmente evidente che non sto nemmeno a spiegarlo.
Il punto fondamentale però è un altro, qual’è l’obbiettivo della selezione qualitativa delle componenti? Offrire una maggiore affidabilità per  ridurre i down (ricordate l’obbiettivo primario di un server?) e garantire la continuità dei servizi.
Proviamo per un attimo ad ignorare le misure di ridondanza spesso presenti sui server (schede di rete, alimentatori, array raid, ram etc etc) e pensiamo ad un guasto, il tempo per riprendere ad erogare il servizio è dato dal tempo necessario a procurarsi il componente da sostituire + il tempo necessario a sostituirlo + il tempo per riavviare il servizio stesso (presupponendo che non si siano verificate perdite di dati o corruzioni degli stessi).
Il punto che mi interessa ora è il primo (il secondo lo tratteremo più avanti), chi può garantire che un certo componente del vostro server assemblato sia disponibile a tempo indeterminato? Molto semplice, nessuno.
Chi può garantirvi degli SLA sui tempi di consegna dei pezzi di ricambio? Nessuno.
Quindi quali garanzie avete che a fronte di un guasto riusciate a procurarvi un pezzo di ricambio? Nessuna.
Una soluzione potrebbe essere quella di procurarsi in anticipo una scorta di pezzi di ricambio, ma questo farebbe lievitare i costi (abbiamo già detto che a parità di componenti i costi di una soluzione “brandizzata” sono già più vantaggiosi), richiederebbe un magazzino, e poi quanti pezzi di ricambio? Chi può prevedere in anticipo quali e quanti guasti si verificheranno nel ciclo di vita di un server?
Ebbene, con una soluzione “brandizzata” e un contratto di supporto semplicemente non vi ponete il problema, i pezzi di ricambio ci sono e ci saranno per un arco di tempo molto più lungo del ciclo di vita massimo ipotizzabile per qualsiasi server.

SUPPORTO TECNICO
Supponiamo che sul vostro server si verifichi un guasto e voi abbiate già in casa tutti i componenti per una sostituzione.
Anzitutto non è banale ne scontato riuscire a trovare velocemente la causa di un problema (da appassionato di hardware vi posso assicurare che certi problemi sulla ram o di alimentazione o sulla mainboard sono tutt’altro che semplici da diagnosticare), in secondo luogo dovete fermare qualsiasi cosa stiate facendo, smontare la macchina, sostituire il pezzo, rimontare tutto e far ripartire il server.
Potrò anche sbagliarmi, ma dubito fortemente che una azienda possa permettersi di pagare una persona per stare perennemente in attesa che si verifichi un guasto e possa intervenire senza interrompere altre attività, persino le aziende che hanno nel loro organico dei sistemisti non si possono permettere questo lusso, pertanto è ovvio che questa attività abbia un costo composto dal tempo impiegato per la riparazione + il tempo perso sulle altre attività su cui era impegnato il tecnico che è intervenuto (e che presumibilmente saranno più redditizie della riparazione del server).
E’ fin troppo ovvio il motivo per cui il supporto tecnico è il vero vantaggio di una soluzione server “bradizzata” e dev’essere sempre tra i primi fattori da considerare quando si prende in esame l’acquisto di una nuova macchina, e non solo per una pura questione di competenze (un tecnico che fa riparazioni per 8 ore al giorno sarà sicuramente più capace e veloce di un assemblatore “della domenica”) ma e soprattutto per una pura questione di costi.
Il costo di un contratto di supporto vi sembra elevato? Provate a stimare quanto tempo vi richiederà la riparazione (anche mezza giornata per certi tipi di guasto), sommate il tempo necessario per farvi recapitare il pezzo di ricambio (min 2/3 gg, ammesso e non concesso che sia ancora sul mercato), ora prendete questo valore e moltiplicatelo per il numero di persone coinvolte (chi effettua la riparazione e chi utilizza il servizio down) e per il costo medio di questo personale, al tutto sommate la mancata produttività di tutti questi durante il down. Vi sembra ancora così caro il contratto di supporto?

PAGAMENTI
Siamo sinceri, tutto quanto ho descritto fin’ora interessa noi tecnici, l’esperienza insegna che se proverete a spiegare tutto questo al vostro capo/manager/direttore gran parte di queste informazioni entreranno da un’orecchio ed usciranno dall’altro… forse solo la parte sui costi relativi al personale fermo per un guasto sortirà qualche effetto.
Tutti sappiamo che per chi si trova a guardare alla “big picture” (insomma i capi…) conta solo l’aspetto economico immediato, mai in prospettiva (ma allora che “big picture” stanno guardando? Mah…).
Proprio su questo aspetto i server “brandizzati” offrono soluzioni di acquisto infinitamente più vantaggiose e che ho notato quasi nessuno degli aspiranti sistemisti conosce; a meno che la vostra attività sia assemblare e rivendere pc, qualsiasi fornitore di hw non potrà darvi altra soluzione di pagamento del bonifico anticipato o carta di credito (scordatevi pertanto le riba), una brutta notizia per il capo…
Nel caso di un server “brandizzato” avrete invece come interlocutore una grande azienda o un grande distributore che offre servizi finanziari spesso molto vantaggiosi, ad esempio noleggio oppure leasing (giusto per citare le due formule più celebri), alla fine vi ritroverete a pagare qualcosa di più (a causa degli interessi) ma potrete spalmare la spesa in molto più tempo, non dovrete più smaltire il bene al termine del suo ciclo di vita (nel caso del noleggio) e sicuramente il vostro capo sarà più propenso ad approvare l’investimento.

Dopo questa lunga pappardella mi sembra ovvio che la soluzione “brandizzata” sia la più vantaggiosa sotto tutti i punti di vista, ho tralasciato alcuni aspetti più tecnici (es monitoraggio) il succo del discorso però è che il server è semplicemente uno strumento di lavoro, lo strumento deve lavorare per l’azienda, non viceversa.

« Post precedenti | Post successivi »