Perché usare distro enterprise?

Uno dei consigli più gettonati nei vari forum per principianti riguardati Linux è:

Non ti funziona $nuova_versione_ambiente_grafico?
Prova $distribuzione_misconosciuta!

La multipolarità della comunità OSS ha permesso la nascita e l’evoluzione di progetti importanti, e la loro gestione “poco business-oriented” ha consentito che si sviluppassero in direzioni spesso più interessanti e funzionali rispetto ad equivalenti commerciali. Dando uno sguardo alla situazione attuale dell’ecosistema Linux però, non si può ignorare come sia il kernel, sia l’ambiente GNU, siano essenzialmente mantenuti da una moltitudine di aziende; gli ultimi rapporti a riguardo parlano di come oltre l’80% degli sviluppatori siano pagati per il loro contributo dalle oltre 1200 aziende attivamente coinvolte: fra i top contributors spiccano Intel, Red Hat, Samsung, IBM, SUSE e Google.

È possibile trovare la concretizzazione di questi contributi professionali e di qualità in una terna (anche se ho delle riserve sul nuovo player) di distribuzioni che chiameremo distro enterprise, ovvero distribuzioni di Linux destinate ad ambienti di produzione per le quali viene offerto supporto commerciale e lo sviluppo/QA viene curato internamente; ci stiamo riferendo naturalmente a Red Hat Enterprise Linux (RHEL per gli amici), SUSE Enterprise Linux e Ubuntu Server.

In questo post volevo esplorare alcuni loro punti di forza che secondo me le rendono una scelta irrinunciabile quando si deve lavorare, in senso esteso, con il computer.
Perché le macchine nascono per fare lavoro al posto dell’uomo, right?

Supporto

La possibilità di poter chiamare qualcuno che risolve qualsiasi problema entro le SLA di contratto e che all’occorrenza rilascia anche patch customizzate è im-pa-ga-bi-le. Fesserie bloccanti che a volte tengono fermi progetti per settimane, di solito vengono risolte in poche ore.

Poiché chi fornisce la distribuzione da assistenza e mantiene/sviluppa tutti i pacchetti presenti nella distro, si riceve supporto anche su Apache, mySQL ecc; a differenza del mondo Windows dove viene garantito solamente il sistema operativo, e si gioca molto allo scaricabarile per qualsiasi software di terze parti. In genere, è possibile mettere su un sistema di produzione con discrete garanzie di fattibilità e tempistiche.

Supporto vuol dire anche manutenzione assicurata a lungo termine: la maggior parte delle distribuzioni succitate offre dieci anni di supporto che comprende patch di sicurezza (e non), chiamate di assistenza, nuovo software… insomma, una piattaforma stabile dove poter sviluppare il proprio workflow senza la paura che ci cambi sotto i piedi.

Compatibilità Hardware e Software

Software di modellazione 3D, schede video high-end, praticamente tutto l’hardware enterprise come HBA, controller RAID e interi servers/soluzioni/infrastrutture… devo aggiungere altro?
Sì: RHEL è una delle poche distro ad implementare correttamente e di default gli attributi estesi per il filesystem (ovvero, le ACL di Windows) e SUSE vanta una compatibilità spettacolare con Active Directory.

Possibilità certificazioni / Prospettive lavorative

Un conto è “so installare Linux, beh, sì“, un altro è poter affermare “sono certificato come system architect per quell’architettura e blablabla“; può fare la differenza.
È costoso, è una mezza mafia, ma può fare la differenza.
Sicuramente conoscere una distribuzione affermata nel panorama enterprise da un marcia in più a parità di curriculum: in generale CentOS è praticamente obbligatoria, ultimamente anche una conoscenza Debian-ish non guasta.

Stabilità

Inutile negarlo, i bugs bastardi esistono anche su Linux, e spesso le soluzioni non sono né triviali né facilmente attuabili at all.
Un ciclo di sviluppo più lento e orientato alla produzione, nonché QA sul codice documentato e funzionalità davvero funzionanti sono il miglior biglietto da visita.

Un esempio? Provate a configurare SELINUX o i pacchetti per l’HA su una distro rolling release.
E poi ditemi.
Ogni pacchetto è generalmente testato-integrato per funzionare bene con tutti gli altri, la distribuzione è un unicum più che essere un’accozzaglia di pacchetti in un calderone, con alcuni presenti solo perché “fa community”, “dobbiamo averli tutti”.
Di contro, il parco software è in genere limitato rispetto ad altre distro; il prezzo del rigore.

Interoperabilità fra versione commerciale e non

La user base delle versioni gratuite (e non solo FLOSS!) di Linux è immensamente più grande di quella delle versioni a pagamento/supportate.

Una dei grandi vantaggi di RHEL e Ubuntu però, è la possibilità di passare in modo assolutamente indolore dalla versione commerciale e supportata a quella community. Ubuntu vende solo il supporto, ergo il problema non esiste. In CentOS/RHEL basta cambiare i repo, le due hanno compatibilità binaria (cambiano loghi e RHN). SUSE/openSUSE pecca un po’ a riguardo, non esiste difatti un equivalente 1:1 di SUSE enterprise.

È possibile scaricare la versione binaria (oltre ai sorgenti, chiaramente) di SUSE e utilizzarla con i corrispondenti repo community, ma la procedura non è esattamente lineare né “caldeggiata”; tutto il contrario di Ubuntu e CentOS, che hanno guadagnato una gran fetta del loro market share proprio grazie all’ecosistema cantinaro e comunitario che si è creato attorno a loro.
SUSE, quando ci svegliamo?
La spinta all’integrazione con prodotti Microsoft ha curiosi riflessi sulle strategie aziendali…

Documentazione

Questo è probabilmente il punto più importante della rassegna, il maggiore selling point; la documentazione di queste distribuzioni, in generale è OTTIMA.
Non parlo di “link al forum, link al tutorial, come ha fatto l’utente XY, prova Z”: ogni funzionalità è completamente documentata e la documentazione è fornita insieme alla distro.

Non mi riferisco al sempreverde man, ma ad interi portali dedicati solamente a spiegare, fornire esempi, aiutare a costruire configurazioni funzionanti.
Aggiornati, corretti, utilizzabili in ogni momento come reference quando ci si trova in difficoltà. Devo dire che sono anche utili per scoprire funzionalità e pacchetti dei quali non si sospettava l’esistenza, semplicemente confrontando “come lo fa SUSE” vs “come lo fa RHEL”.

Un consiglio?

Per lavorare, fintantoché potete e non sorgono delle difficoltà insormontabili, usate CentOS. La maggior parte delle soluzioni enterprise sono sviluppate sopra di essa, dai firmware delle SAN; è bene farsi le ossa sugli ambienti realmente utilizzati in produzione. Se si resta sui repo standard, fatta salvo ovviamente una configurazione corretta, è incredibilmente stabile: la uso correntemente sia come hypervisor (KVM) che come host.

OpenSUSE/SUSE ha molto senso come ambiente desktop: ottima con KDE4, grande integrazione di default con eventuali sistemi Microsoft o altre terze parti. Inoltre, ultimamente sta prendendo molto piede come piattaforma di storage grazie al supporto per CEPH. La suite di High Availability e supercalcolo dicono funzioni molto bene, ma generalmente sono campi dove si customizza parecchio.

Ubuntu… sta guadagnando molta popolarità in installazione di OpenStack. Per il resto, la documentazione è poco affidabile/aggiornata/completa rispetto agli altri contenders, e la selezione del software spesso è fatta in modo scellerato, solamente per includere features consumer a scapito della stabilità; come si può includere un kernel NON lts in una release lts?! Di contro, è molto aggiornata e alcuni progetti proposti da Canonical sono interessanti (penso a LXD), ma la consiglierei solamente se è impossibile raggiungere il vostro scopo utilizzando le altre due alternative.

La grande O nel cielo

Francamente? Io un’idea a riguardo cel’avrei.

Con quello che è rimasto dell’azienda, assumete una trentina di programmatori/sistemisti/hardwaristi Linux; si trovano abbastanza facilmente, basta fare screening fra i certificati Red Hat. Fategli sviluppare un sistema centralizzato “All inclusive” per le PMI, dalla ricezione mail alla bolla da appiccicare sul pacco, che giri tutto su un server (o due, DRBD + clustering applicativo), basato su Linux/KVM; lo stack è già tutto esistente, dall’hypervisor alle applicaizioni client, basta integrarlo e farne un prodotto fico.

Sfruttate quel cazzo di nome, fate le porte dell’armadio con un grande O verde a triangolini, scrivetegli sotto POWERED BY LINUX e pubblicizzatelo con delle rassicuranti schermate che non dicano “Cloud, 2.0, IoT”, ma che facciano vedere un sistema con le finestre e i menù come dio comanda, ché la gente si è rotta delle ultime schizofrenie tablet-style Microsoft (infatti compra Apple) e nella “flessibilità degli applicativi pensati anche per il mobile” ed altra fuffa mediatica crede sempre meno.

Cosa mettiamo stasera nel minestrone.

Virtualizzato, potente, veloce (già quattro HDD e una buona cache sanno il fatto loro, per 20 dipendenti), che può crescere insieme all’azienda; ci vuol nulla, deployando tutto come VM. Dentro mettetegli un fileserver, un mailserver, un proxy squid che lavora in whitelisting per alcuni e in blacklisting per altri (ah, già vedo i sorrisi del CEO!), ammenicoli per la VPN/firewall, un sistema ERP come OpenBravo. Fateli testare ed integrare bene almeno un annetto… con tutto l’hardware che venderete al corredo, sopratutto il sottosistema di stampa e i POS; lì, avete tonnellate di know-how.

Validate le ultime incarnazioni di LibreOffice, magari anche con plugin proprietari per la conversione da ooXML (esistono eccome, e funzionano bene!), al resto pensa il motore LaTeX che gestisce l’output dall’ERP; niente rocket science, si tratta di scrivere un paio di parser da applicare a dei modelli, eventualmente personalizzabili. Assomiglia molto al lavoro di integration che spesso viene demandato ai sysadmin o ai dbadmin.

E il coccodrillo?

Riguardo i clients, fornite della roba ARM o MIPS che utilizza X over ethernet verso delle VM sul server; X11 funziona egregiamente in LAN, non molto in WAN. Qualora si dovesse scalare, SPICE ha fatto passi da gigante ed è abbastanza utilizzabile. Macchinette da 20 euro al pezzo, da rivendere a 150 con la grande O verde, stando ancora molto sotto quanto viene chiesto oggi per un thin client.

Per i servers: i dual socket commodity x86 con le features RAS vanno già benissimo per poter sostenere la “responsabilità operativa” di un’intera azienda di queste dimensioni, senza far casini con storage di rete e quant’altro, che su questa fascia di prezzo minerebbero l’affidabilità dell’insieme (lo spiegavo qualche post fa). Nel settore c’è fermento nonostante la commoditization, sono parecchi i vendors che sgomitano: Huawei, dice nulla?. Volendo, se la cosa dovesse scalare diversamente, si potrebbe portare tutto già oggi su ARM o POWER senza salti mortali.

Tutto E/O niente

Bisogna fornire il rack completo, già precablato e labelizzato (mezzo rack dovrebbe bastare per la maggior parte delle PMI), includendo il poco networking, un NAS per i backup in situ (più un altro in remoto, o comunque altrove, che replica gli snapshots delle VM); un paio di UPS correttamente dimensionati, magari anche filtrati; la soluzione è pensata per aziende che non hanno un comparto IT, non vogliamo che il primo ingegnere elettronico di turno ci metta le mani, no?

Qualcosa che altri hanno già pensato di fare, ad esempio Dell con vStart e la stessa VMware con VCE, solamente a prezzi di un ordine di grandezza superiore. La differenza con questi giganti è la facilità di gestione per la PMI, che sarà molto scoraggiata dal mettere le mani su QEMU e combinar casini, piuttosto che farlo su HyperV o l’interfaccia web di vSphere; già, il minimalismo come baluardo, e contraltare degli infiniti databases, API e framework immensi che oggi si devono usare anche per gestire installazioni su piccola scala.

Otteniamo così un sistema centralizzatISSIMO, sul quale si può fornire assistenza top-down, che consuma poco ed usa le risorse (storage locale, sistema scale UP) in modo intelligente (containers, VMs che condividono la stessa golden image, networking quasi tutto interno al singolo nodo), e può soddisfare il 99% delle esigenze delle PMI che partono da zero, o quasi. Nessun casino con malware &co. (SELINUX è tuo amico), nessun aggiornamento idiota che blocca l’operatività.

Qualora una VM client dovesse avere un problema, con le funzionalità standard di qualsiasi distro enterprise odierna è già possibile ricreare la macchina da un template (scriptato con Puppet ovviamente) in pochi SECONDI, da remoto con Mosh o SSH + DynDNS. Così, si può fornire assistenza remota senza mandare i sistemisti in situ anche sulla più misera delle ADSL (ho fatto esperienza pure sul 3G). Alla bisogna, si fornisce anche la possibilità di collegarsi a delle VM Windows, e ci si può anche sobbarcare la conversione dei vecchi documenti da formato “Office” a ODF.

Ok, ma…

Fornire tutto ciò in comodato d’uso, un TOT al mese, gestendo l’hardware usato (che così si può riutilizzare fino a “fine vita”) non è una banalità, ma mi sembra raggiungibile con le cifre lette nell’articolo, in due-tre anni. Sempre meglio che morire di fame rimarchiando tablet.

È antiquato, sembra un ritorno ai vecchi AS400? Sì, esatto. CHE DIFATTI, FUNZIONAVANO. Vedo ovunque un grande bisogno di ritorno a soluzioni più “commensurabili”, comprensibili, architetturalmente meno articolate, e che nascondano meno la loro complessità; in una parola: semplici anche se non necessariamente facili… dove facile che è un concetto relativo: vi sembra “facile” utilizzare Metro per task avanzati o metter su un cluster di active directory perché il database potrebbe corrompersi random in qualsiasi momento? Ma, sopratutto dover dialogare con sistemi che dipendono in modo assolutamente vincolante dal buon funzionamento di DNS&co. (cosa abbastanza fragile), la cui gestione viene spesso affidata al primo santone di tutto che “sa installare Windows”, e questo anche per installazioni da una decina di postazioni?

Non credo che ci sia mai stato un momento più propizio per l’ingresso di una soluzione di questo tipo (Linux desktop e server, tutto virtualizzato a la “mainframe x86”), dati i pesanti colpi accusati da Microsoft ed un drammatico calo dei costi di storage e server di bassa gamma, insieme alla sostanziale scomparsa delle soluzioni prima denominate midrange da questa fascia di mercato (ex system P, system i, AS400 ecc.); manca solamente un’azienda agile, che abbia voglia di fare il primo passo.

Ah, mi dicono che il logo sia diventato rosso, adesso.

The birth and death of RAID

Le prime notizie relative al RAID risalgono alla fine degli anni ’70, quando le macchine UNIX midrange iniziarono a dotarsi di quello che oggi chiameremmo “RAID Software”; prima c’erano solo sistemi per la correzione di errori in memoria, ma di tipo offline.

Pubblicità progresso

Fa sempre bene ricordare come il RAID non sia una soluzione che riguarda la sicurezza dei dati: il RAID è una soluzione che riguarda la continuità del servizio. Ovvero, un array RAID permette di continuare a lavorare durante un guasto, ma è implicito che ci si debba immediatamente prodigare per sostituire il componente guasto e non si possa fare a meno di un sistema di backup.

Il RAID non sostituisce il backup, mai: sono due sistemi concettualmente ed operativamente diversi; se il RAID è online (cioè utilizzato per l’accesso ai dati di lavoro), e garantisce la continuità del servizio, il backup è invece offline, off-site e fornisce archiviazione, conservazione e sicurezza dei dati. Il backup in genere è una soluzione di disaster recovery, il RAID è risk mitigation.

SCSI Golden Age

L’utente medio ricorderà probabilmente i controller entry level Adaptec o LSI dei primi anni ’90, nati principalmente per supplire allo scadente RAID software integrato in Windows… ancora oggi parecchio deficitario rispetto all’esemplare implementazione di md su Linux. Le tipiche configurazioni prevedevano RAID 5, tre-cinque dischi (rigorosamente dispari, per agevolare il calcolo della parità)… fino all’inizio degli anni 2000, i dischi costavano parecchio e non c’erano alternative in quella fascia di prezzo.

Inoltre, le CPU x86 erano ancora pressapoco dei giocattoli, che mal sopportavano l’overhead dei livelli RAID con parità. I SO avevano ancora una gestione delle code di I/O abbastanza primitiva; l’offloading del calcolo all’ASIC del controller era una manna dal cielo. Da metà degli anni ’90 il RAID hardware in qualsiasi macchina server viene considerato praticamente obbligatorio, e in una decade diventa commodity.

Ogni array che si rispetti ha i suoi dischi SCSI da 73Gb a 10kRPM, il RAID 5 regge perché il fallimento dovuto ad URE è abbastanza improbabile date le dimensioni degli HDD. Da segnalare anche la diffusione nelle motherboard consumer dei cosidetti “FakeRAID“, implementazioni puramente software e supportate quasi unicamente da Windows. Sono generalmente non troppo prestazionali o affidabili, e poco impiegate in ambito enterprise.

Per dipingere una parete grande, ci vuole un pennello grande

Saltiamo avanti di due decenni, siamo negli anni 2010 (chissà che convenzione tireranno fuori riguardo queste decadi, al momento lo scrivo per esteso): i dischi raggiungono capacità di svariati Tb, il costo dello storage è in caduta libera, il fallimento per URE mette fuori dai giochi i livelli RAID con singola parità.

Il RAID 10 viene universalmente adottato in ambito enterprise, affiancato dal RAID 6 o livelli proprietari (aventi comunque almeno doppia parità) per l’archiviazione massiva. Assistiamo inoltre ad una ulteriore evoluzione del RAID software: le prestazioni delle CPU rendono md più che adeguato per la maggior parte degli array-use_case; inoltre, con la comparsa di ZFS l’utente può usufruire di un filesystem che fa anche RAID (con tripla parità!) e volume management avanzato… permette anche di impostare dispositivi per il caching! Ciononostante, il RAID hardware viene ancora preferito in sistemi di produzione per alcune caratteristiche avanzate:

  • possibilità di fare caching con analisi euristica dei blocchi più utilizzati su cache molto grandi (anche decine di Gb);
  • blind swap, ovvero sostituzione dei dischi a caldo e ricostruzione dell’array senza nessun altro intervento da parte dell’operatore (spostando la gestione dell’array dal system admin all’operatore hardware);
  • batterie interne, che anche in caso di totale failure dell’alimentazione permettono al controller di terminare le scritture o almeno memorizzarle su dispositivi a stato solido fino al successivo recovery;
  • replica remota su altri controller con latenze molto basse;
  • OS-agnosticità, tanto da poter essere montati su dispositivi come SAN, NAS, DAS ecc.

Il RAID è una pratica ormai assolutamente standardizzata e implicita in ogni installazione di un certo livello.

…and thanks for all the bits

E allora, perché nel titolo parlo di morte del RAID? La domanda da porsi è se il concetto di unità di storage in RAID (per come lo intendiamo oggi, assistito da un controller hardware in particolare) abbia ancora senso con l’avvento degli SSD di nuova generazione, per i seguenti motivi:

Prestazioni del bus

Sfruttando le connessioni PCI-E (o, ultimamente, gli slot della RAM), gli SSD permettono prestazioni teoricamente equivalenti alle massime ottenibili da un controller RAID, poiché sfruttano lo stesso bus di sistema per comunicare con la cpu.

Parallelismo/Prestazioni

Le maggiori prestazioni ottenuti dai controllers compiendo I/O in parallelo su dischi rotazionali, oggi sono replicabili leggendo o scrivendo in contemporanea (striping) da un numero praticamente arbitrario di NAND, solamente “limitato dal controller”; questa volta, quello dell’SSD.

Da qui la crescita esplosiva nelle prestazioni degli ultimi SSD messi in commercio, che arrivano a picchi di quasi 4Gb/s (GigaBYTE, non Bit) R/W, con latenze bassissime. E se ci sono ancora obiezioni sulla capacità, basta guardare agli ultimi ritrovati.

Parallelismo/Affidabilità

La maggior affidabilità del RAID di dischi rotazionali (RAID 10, ovviamente) è data dal poter eseguire letture e scritture in parallelo (stavolta, cloning) su “pezzi di hardware” distinti, e grazie ad uno strato software di recuperare eventuali fallimenti… esattamente ciò che viene fatto NAND per NAND dagli attuali SSD enterprise, che spesso espongono una capacità effettiva minore (anche del 30%) per potere, grazie alla logica del controller, tenere alcuni settori spare che generalmente vengono utilizzati come settori di parità a la RAID con parità (multipla!).

Questa architettura sembra funzionare molto bene per via dell’enorme numero di nodi per stripes e il grande “dominio di parità”; il controller riesce a tenere conto con discreta precisione dello stato di salute delle singole componenti, e generalmente rimpiazza le NAND che si avvicinano a fine vita con quelle precedentemente tenute a riposo prima che ci possa essere un sostanziale degradamento di prestazioni o affidabilità. Un esempio di queste funzionalità viene molto chiaramente descritto qui.

So what?

A mio parere, ci avviciniamo ad un cambio di paradigma nel quale il supporto di memorizzazione a stato solido sarà affidabile e prestazionale quanto un controller RAID, rendendone di fatto superfluo l’utilizzo, limitatamente almeno allo storage locale. La battaglia si sta già svolgendo, specialmente fra gli algoritmi per il wear-leveling e livelli di RAID-ridondanza “interni”; ne parlano molto gli ultimi papers di IBM sui loro nuovi storage all-flash e altri di Intel e FusionIO.

Costano troppo? Space-wise, ancora per qualche anno. IOPS-wise, c’è già stato il sorpasso. Per fare gli IOPS di un SSD enterprise ci vogliono una batteria di dischi SAS più un controller RAID con una cache mica da ridere… e se non li puoi hostare dentro la macchina singola, ti serve anche una SAN, che presa da sola peggiora l’affidabilità del sistema. Altrimenti ne servono due, con due switches FC, HBA ridondanti, ecc; ed ecco che la soluzione con storage locale torna ad essere concorrenziale sia sul prezzo che nella semplicità di gestione, magari assistita da una replica block-level.

Naturalmente, lo use-case che immagino è quello di workload mission-critical; non certo di quello di consolidamento dello storage nel quale latenza, prestazioni pure e semplicità dell’infrastruttura passano in secondo piano.

L’insostenibile leggerezza dello specchio

Si parlava ovunque della imminente scomparsa delle DSLR a favore delle mirrorless; passato l’hype (che aveva preso un po’ anche me, non lo nego) del mercato e dell’opinionista fotografico medio, possiamo inquadrare meglio il topic dal punto di vista dell’utilizzatore prosumer/professionale. A mio parere, le DSLR sono qui per restare. Ancora per molto, molto tempo. Ne sono così convinto, che una delle mie ultime acquisizioni è stata proprio un’ottica manual focus per DSLR. Proviamo a capire perché.

Autonomia

Una DSLR avrà sempre un’autonomia superiore a parità di sensore rispetto ad una mirrorless, perché può tenere attivo il sensore soltanto poche frazioni di secondo versus tutto il tempo che serve per comporre l’inquadratura e mettere a fuoco. Ovvero, resta con una buona fetta dell’elettronica “spenta” durante buona parte dell’utilizzo; al contrario, in una mirrorless il sensore deve essere sempre acceso per focheggiare, misurare la luce ecc. Questo inoltre riscalda il sensore, lo rovina prima, crea rumore termico, richiede batterie più grandi.

Dimensioni

Batterie più grandi vogliono dire dimensioni più grandi e potrebbe anche succedere che una DSLR, a parità di autonomia, abbia dimensioni complessive più piccole di una mirrorless (si recupera lo spazio mirabox con il supplemento di batteria). La cosa potrebbe andare bene per macchine poco professionali da 300 scatti a carica, ma per qualsiasi impiego di reportage, il gioco si fa duro…

Non dimentichiamo inoltre che le dimensioni complessive sono influenzate anche dai comandi: a parità di numero di ghiere e pulsanti, la cui numerosità e dimensionamento è dettata da esigenze operative e fisiologiche precise, non vedo particolari vantaggi dimensionali delle mirrorless su un corpo macchina professionale. Inutile girarci attorno, ma un corpo PRO deve avere delle dimensioni simili alle attuali ammiraglie Nikon e Canon (D4s e 1Dx) per consentire una impugnatura salda e comoda anche in posizione verticale e con ottiche voluminose e pesanti.

Corredo

Bisogna considerare che il corpo macchina è spesso una componente dimensionalmente minoritaria rispetto a tutto il resto dell’attrezzatura professionale, pensiamo a luci ed ottiche… spesso questo “schiacciante” vantaggio a favore delle mirrorless è stato eccessivamente enfatizzato dal marketing, ma non dimentichiamo che esistono delle precise motivazioni ottiche per le quali un 300 f2.8 non può essere parecchio più piccolo degli attuali.

Qualità delle ottiche

Esistono vantaggi reali nell’eliminare il box specchio dal punto di vista del design ottico, sopratutto nel design di ottiche grandangolari. La loro focale infatti spesso è minore delle dimensioni fisiche occupate dallo specchio; ovvero, dovremmo ritrovarci con il nocciolo ottico dentro lo specchio… la cosa viene risolta (vado molto a spanne) disegnando un grandongolare standard e aggiungendo un “telescopio” che permette la corretta formazione dell’immagine sul sensore anche se tutta l’ottica dista dal sensore parecchio più della distanza focale. Questo vantaggio esiste solamente per focali dai 50mm in giù; già sopra i 35mm all’incirca, (lo spazio retrofocale occupato dallo specchio) gli schemi ottici sono abbastanza equivalenti.

Inoltre, i sensori digitali hanno messo in luce un limite dei grandangolari simmetrici: per ovvie motivazioni ottiche, i raggi ai bordi del circolo di copertura arrivano parecchio inclinati sul sensore. Sembrano esserci problemi con CCD e CMOS rispetto alla pellicola: se quest’ultima offriva una superficie sensibile praticamente piatta (anche se sul colore avremmo potuto vedere qualche shift dato dalla profondità dei layers), i sensori digitali possiamo immaginarli con pixel formati da scatole quadrate senza una faccia (dalla quale entra la luce) e la superficie sensibile sulla faccia opposta.

Va da sè che parte dell’informazione luminosa si perda sulle facce non sensibili al crescere dell’angolo con il quale incide la radiazione. A riguardo, Leica/Dalsa sembrano avere risolto la problematica aggiungendo delle microlenti (stile Fresnel) sulla superficie del sensore, che unite ad un profiling software di ogni lente fanno un ottimo lavoro. Comunque, fino a 20mm gli schemi retrofocus del mondo reflex non si difendono malaccio, basti pensare a quelle meraviglie degli Zeiss ZF.

Messa a fuoco

La precisione del live view confrontato con il mirino ottico senza magnificazioni (0.8x rispetto all’ottica 50mm) è leggermente a favore del mirino digitale, che offre il lusso del di poter cambiare l’ingrandimento alla bisogna; mi chiedo però se sia realmente possibile focheggiare un 135mm a mano libera guardando i pixel 4:1… Un buon mirino ottico con la giusta magnificazione (io uso il DG-2 su Nikon, prima avevo un KatzEye sulla digitale), può ancora vincere in un contesto di reportage d’azione.

Ovviamente, per qualsiasi impiego dove la precisione pixel-level è un requisito, il live view è comunque necessario. Tutti i corpi reflex attuali offrono il live view a richiesta, ne segue che per impieghi di tipo studio le due piattaforme sono abbastanza interscambibili. Inoltre, avere in più il mirino ottico sempre attivo offre una visione più rilassante, disponibile anche a macchina spenta.

Inerzia

Ci sono interi standard industriali che si basano sulla baionetta di certe reflex (pensiamo all’attrezzatura scientifica in montatura Nikon), oltre al workflow della quasi totalità dei professionisti sulla piazza. Tonnellate di accessori, supporti, un intero ecosistema economico gravita attorno alla tecnologia delle reflex; come per certe tecnologie informatiche… avete presente il COBOL? Dagli anni ’80 ad oggi l’avranno dato per morto una ventina di volte; fatevi un giro su LinkedIN e vedete quanto siano richiesti oggi i programmatori COBOL. Il legacy è una brutta bestia, ma è anche dove le aziende investono, è la base sulla quale costruiscono il loro business.

Alcune noncuranze

Non per problemi tecnologici o architetturali, ma ancora il segmento mirrorless presenta delle lacune eccellenti:

  • Niente corpi professionali al momento, e non sembrano in arrivo rapidamente. Ricordiamo che no corpi pro => no ottiche pro. La rigidezza è tutto.
  • Nessun modello attuale ha un sistema di flash TTL maturo, o almeno usabile in contesti produttivi.
  • User base piccola, e quindi nessun grosso investimento in massiccio in R&D; il mercato langue, non ci sono grandi novità all’orizzonte. Paradossalmente, è molto più vivace il segmento dei dorsi digitali medio formato, che stanno finendo di soppiantare il 4×5.

Quindi, tranquilli: DSLRs aren’t going anywhere.

Sulla mistica dello storage enterprise

Quello dello storage non-consumer è sicuramente uno dei settori dell’IT più floridi per quanto riguarda la nascita di miti e leggende: cosa favorita, oltre dal marketing dei big players, dall’oggettiva complessità di alcuni concetti in gioco e dalla diffusa ignoranza degli uomini-IT in merito.

Vediamo di semplificare un po’, dando delle descrizioni “operative”.

DAS

Né più né meno dello storage interno del vostro server, ma ospitato in una enclosure esterna; da vedere come una “unità di espansione dischi” o “moltiplicatore di porte SAS esterno”. Generalmente il collegamento alle macchine avviene tramite cavi SAS (gli stessi che collegano i dischi locali), lo storage viene visto esattamente come uno o più dischi interni alla macchina.·

Come un qualsiasi controller SAS interno, sono muniti di funzionalità RAID e permettono di esporre partizioni, “array” dell’aggregato di dischi fisici, presentati alla macchina come normalissimi dispositivi a blocchi AKA dischi interni.

SAN

È qui che si concentrano la maggior parte degli equivoci, quindi diciamolo subito: la SAN non è altro che un DAS esposto ai servers tramite un protocollo di rete (iSCSI, FC, FCoE). Fine. Più precisamente la Storage Area Network è un insieme di dispositivi, composta oltre dalla parte al quale viene generalmente attribuito il nome SAN, anche dagli switch e dagli HBA presenti sui servers; è giustappunto un network, non un singolo dispositivo.

È quindi possibile fare switching e routing del flusso di dati riguardanti lo storage, oltre a poter utilizzare il tutto in direct-attach similmente al DAS. Cosa? Routing dello storage? Pazienza Iago, pazienza.

NAS

Questo lo conosciamo bene tutti; un NAS è un fileserver che permette la condivisione dello storage a livello del filesystem, ovvero incorpora tutto lo stack necessario a presentare ai servers files e cartelle. Questo è l’unico dispositivo fra quelli presi in esame a permettere l’accesso allo storage a livello di files e non di blocchi; cioè, non è permesso accedere direttamente all’array di dischi fisici per partizionarlo, formattarlo ecc. Inoltre è l’unico, e sottolineo l’unico, ad incorporare la logica necessaria a gestire l’utilizzo in concorrenza di più macchine ad uno stesso pezzo di storage.

E allora?

Come, la SAN non serviva per “condividere lo storage” fra più macchine? NO. La SAN nasce principalmente per semplificare e rendere più efficiente la gestione dello spazio su disco di installazioni molto dense con parecchi servers, poiché è parecchio più semplice assegnare una LUN ad un server piuttosto versus spostare fisicamente (con ricostruzione array e quant’altro) dischi fra più macchine. In questo modo, è possibile assegnare dinamicamente “dischi” di dimensione variabile al server, senza interventi fisici e interruzioni dell’operatività: il punto che si possa fare su più macchine contemporaneamente, condividendo i dischi fisici, è la ragion d’essere della SAN.·

In realtà, anche il DAS può fornire funzionalità di questo tipo se le macchine sono poche e abbastanza vicine allo storage, collegando direttamente i servers allo storage. Nella caso della SAN, sia essa FC, FCoE o iSCSI, è addirittura possibile collegare lo storage e i servers a degli switch e persino a dei router in configurazioni simili a quelle di una tradizionale LAN, che permettono ad esempio di realizzare configurazioni che hanno particolari caratteristiche di resistenza ai guasti (utilizzando più SAN in replica, ad esempio).

Andiamo oltre adesso; collegate due macchine fisiche alla stessa LUN di una SAN (con dei dati all’interno, magari): vi ritroverete con un filesystem irrimediabilmente corrotto dopo qualche secondo, e la totale distruzione dei dati sarebbe cosa inevitabile dopo pochi tentativi di scrittura. Perché? Perché collegare una SAN a due macchine, è come collegare un ideale hard disk fisico con due cavi SAS a diversi computers: alla prima operazione contemporanea, vi ritrovate con un ammasso di bit insignificanti. C’è un solo modo per gestire un hard disk condiviso fra due macchine: un filesystem distribuito, detto anche clusterizzato.

SAN != File Sharing

L’errata considerazione della SAN come “storage di files condiviso” a mio parere nasce dalla grande facilità d’uso di VMFS di VMware, che permette l’uso “trasparente” della SAN, presentando gli array agli utenti proprio come farebbe un NAS, cioè come spazio formattato nel quale è possibile effettuare operazioni in concorrenza sui files. Ma attenzione: come nel caso del NAS, è il filesystem che si occupa di gestire la concorrenza, questo nulla ha a che vedere con le caratteristiche della SAN. Provate a configurare un filesystem clustered come GPFS o GFS, se volete capire profondamente come funzioni la cosa; è sempre bene sporcarsi un po’ le mani per arrivare ad una comprensione piena di certi meccanismi.

Performance

La tipologia di storage più performante in assoluto continua ad essere quello interno ai servers, ancor di più con il recente affermarsi di ssd PCI-E e memory-channel. Lo storage di rete, sia esso SAN o NAS (e in una certa misura anche il DAS) è comunque limitato dall’overhead del protocollo di rete e dalla sua larghezza di banda. L’ultima versione del FC quota 16Gbit/s, appena uscito e dai prezzi folli… Il PCI-E 3.0 16x fa circa 126Gbit/s, oggi, per slot, e sono già uscite le specifiche del 4.0 che avrà esattamente il doppio di banda; cambia poco negli ordini di grandezza se consideriamo iSCSI. Il DAS ha generalmente poco overhead, scala in termini di multipli interi di porte SAS a 12Gbit/s.

Keep it simple, stupid!

Tutto questo può essere letto come un invito a semplificare il più possibile la topologia dello storage: si guadagna in prestazioni, si risparmia, si ottiene un’affidabilità maggiore; la crescita di complessità può essere giustificata solamente quando non è assolutamente possibile soddisfare i requisiti progettuali senza aggiungere componenti o layer di astrazione.

In generale, lo storage locale è sempre da preferire a tutte le altre alternative; la “catena cinematica” è la più corta, ciò porta a meno connettori/interfacce che possono guastarsi (o fare contatto intermittente, che è una delle cause più comuni del fail nei raid con parità), minore latenza e prestazioni massime, oltre che semplicità di gestione. La crescita di dimensioni dello storage può urtare i limiti fisici del singolo server, ed ecco che abbiamo bisogno di un DAS per la scalabilità. Gli ambiti dove è opportuno utilizzare NAS e SAN enterprise dopo l’avvento dei meccanismi di replica software block-level e file-level, sono sempre più ristretti; in particolare, nel caso della SAN è necessario avere del personale iniziato ai misteri della condivisione block-level ed una infrastruttura abbastanza ridondante, cosa che spesso si traduce in esborsi non indifferenti e difficilmente giustificabili nel mondo delle PMI.