Una panoramica sul mondo della Sicurezza Informatica, del Networking, della Virtualizzazione e non solo. Blog particolarmente indicato per i reparti IT che comunque alterna articoli scritti per specialisti con articoli formulati con linguaggio semplice e comprensibile a tutti.

Ogni articolo di questo blog è stato integralmente scritto dall'autore. Il contenuto è completamente originale e la riproduzione, anche parziale, è vietata salvo autorizzazione.

mercoledì 20 marzo 2019

NAS e SAN con dischi SSD: come commettere facili errori

I dischi SSD ormai hanno costi accessibili e capienze accettabili, non è inusuale che vengano preferiti ai dischi magnetici. Anche se nella maggioranza dei casi questa preferenza è sempre conveniente, quando dobbiamo dimensionare un NAS o una SAN esterna, è facile vanificare la spesa commettendo errori banali sulla parte di interconnessione. Come dire, possiamo anche avere una Ferrari, ma se la mia destinazione si raggiunge solo percorrendo una polverosa strada di campagna, avrò solo speso soldi senza aumentare la mia velocità effettiva.
Mi sono imbattuto casualmente in una discussione in cui si elogiavano le performance dei dischi SSD su un NAS, andiamo a capire perchè questo non può essere vero, e lo facciamo con dei numeri.


NAS o SAN?

Tanto per iniziare, capiamo le differenze. Una SAN presenta le LUN direttamente al sistema operativo, in maniera trasparente.

Un NAS invece si fa carico di strutturare un file system e lo presenta in maniera organizzata, meno immediata, tramite un protocollo applicativo, ovvero ad un livello decisamente superiore.

Ho preparato un breve schemino per renderlo più digeribile pur non avendo enzimi specifici:




A cosa ci serve? Parliamo di performance, quindi ogni aspetto è importante. Appare evidente che un NAS deve elaborare, e questo non va molto d'accordo con l'economicità dei prodotti spesso in circolazione. Le CPU dei piccoli NAS in giro (tipicamente fino a 4 baie) sono spesso totalmente insufficienti a non creare un collo di bottiglia proprio in questo punto. Posso mettere i dischi più veloci del mondo, ma la CPU deve stare al passo.



Interconnessione


Qui c'è l'aspetto più importante. Nel mio storage, SAN o NAS che sia, posso fare un array anche full SSD, ma poi la parte di accesso riuscirà a garantirne il troughput? Ed è qui che casca spesso l'asino.

Nell'architettura NAS, utilizzerò le schede di rete in dotazione all'apparato e chi avrà accesso allo stesso, farà la medesima cosa. Molto spesso non è dedicata una NIC alla parte storage, ma questa viene condivisa anche con la parte network (peggiorando la situazione).

Nell'architettura SAN, invece, ho più scelta. Posso utilizzare la parte network, ma potrei farlo acquistando una scheda di rete con supporto iSCSI TOE che accelera a livello hardware tutta la parte SCSI over IP. Ma ho anche un'altra alternativa, utilizzare un'interfaccia FibreChannel, per sua natura estremamente veloce (e che introduce meno latenza del rame, ma non voglio spingermi oltre anche con questo aspetto che comunque è importantissimo nel dimensionamento della parte storage).



Qualche numero per capirci


Il dimensionamento di uno storage è uno degli esercizi sistemistici più complessi, ed è mia prassi effettuare, prima di consegnare ogni SAN che vado a dimensionare, accurati test (non meno di 1 giorno) di performance per capire cosa può essere migliorato ed in che maniera. Il risultato è che questi numeri (che qui sono stati barbaramente banalizzati) sono il frutto di dati reali, raccolti in molteplici anni di accurate verifiche.

Dischi:

I dischi vanno misurati in IOPS, tuttavia per rendere un dato più intelleggibile con la componente network, mi concederò una licenza ed esprimerò dei numeri in MB/s di lettura sequenziale senza cache, che certamente faranno sobbalzare i puristi.

  • 1 disco SATA 7400rpm: circa 80MB/s
  • 1 disco SAS 10k: circa 120MB/s
  • 1 disco SAS 15k: circa 140MB/s
  • 1 disco SSD: circa 600MB/s 
  • 4 dischi SATA in RAID5: Circa 320MB/s in lettura
  • 4 dischi SAS 10k in RAID5: Circa 480MB/s in lettura
  • 4 dischi SAS 15k in RAID5: Circa 560MB/s in lettura
  • 4 dischi SSD in RAID5: Circa 2400MB/s in lettura
Numeri estremamente imprecisi, che variano da disco a disco, da raid a raid, da file system a filesystem... ma è solo per avere un'idea molto di massima. NB: Con il raid5 abbiamo un penalty di 4 nella scrittura, all'aumentare delle meccaniche aumentano anche ovviamente le performance (ma anche qui, ci spingeremmo troppo oltre).

Interconnessione:

Prendiamo come esempio solo l'architettura più veloce, ovvero immaginiamo di avere una SAN. Con un NAS le cose peggiorano drammaticamente, ma non è questo il punto.
  • iSCSI 1Gbit senza TOE 1500MTU: 97MB/s
  • iSCSI 1Gbit con TOE 1500MTU: 117MB/s
  • iSCSI 10Gbit senza TOE 1500MTU: 560MB/s
  • iSCSI 10Gbit con TOE 1500MTU: 720MB/s
  • iSCSI 2x10Gbit in RoundRobin con TOE 1500MTU: 1046MB/s
  • FibreChannel 1x8Gbit: 790MB/s
  • FibreChannel 2x8Gbit in RoundRobin: 1220MB/s
  • FibreChannel 1x16Gbit: 1380MB/s
  • FibreChannel 2x16Gbit in RoundRobin: 1900MB/s
Purtroppo non ho ancora dati sul nuovo FC a 32Gbit.

Anche qui, numeri condizionati dai sistemi su cui ho effettuato le misurazioni, in anni diversi e in situazioni diverse. Inoltre sono numeri ottimistici, fatti sempre su macchine che avevano come costo minimo 35-40.000 euro, non certo sui nas da 160 euro . Ma è solo per capirci.


Morale della favola


Il morale della favola è semplice e si evince facilmente. Mettere dischi SSD su un NAS da 400 euro non serve a niente. Se poi l'accesso avviene in maniera diretta dai client con una misera NIC in gigabit, serve ancor meno. Per sfruttare i dischi SSD su uno storage esterno, avrò bisogno come minimo di collegarmi in FibreChannel a 16Gbit (o con due da 8). Architettura, questa, tipica di un'infrastruttura virtuale ben dimensionata.




Edit: Mi è stato fatto notare che ho omesso la tecnologia SAS. Vero: non ho sufficienti dati per citarli. Allo stato attuale personalmente ritengo sia più economico utilizzare iSCSI e più performante utilizzare FC, pertanto le interconnessioni SAS nel corso del tempo, nel mio caso specifico, hanno trovato sempre meno campi di applicazione.



Discaimer: Ogni articolo di questo blog è stato integralmente scritto dall'autore. Il contenuto è completamente originale e la riproduzione, anche parziale, è vietata salvo autorizzazione.


giovedì 7 marzo 2019

Programmi di bugscouting: come guadagnare legalmente con l'hacking

Forse non tutti conoscono le piattaforme di bugscouting. Uno dei più famosi è HackerOne. La piattaforma mette in comunicazione le aziende e gli hacker. Le prime si impegnano a riconoscere ai secondi una ricompensa (un bounty) qualora questi identifichino un bug di sicurezza che rientri in determinati canoni.

Questo, ad esempio, è il bounty policy di NextCloud (https://hackerone.com/nextcloud):


Scorrendo nella sezione hacktivity è possibile vedere le ultime vulnerabilità scovate. Particolare interesse generano i servizi finanziari, ad esempio questa schermata è quella di Paypal. Alcuni casi sono ovviamente secretati, questo avviene spesso nel caso in cui la soluzione al problema richieda del tempo, ma è una politica aziendale (Intel, ad esempio, secreta tutto, a differenza proprio di NextCloud).


Bhè, non c'è che dire, i dati parlano chiaro, Paypal ha pagato quasi 1 milione di dollari in ricompense, e di recente i casi riportati hanno avuto in media dai 18.000 ai 23.000 dollari di bounty.


Cliccando sull'hacker che ha più contribuito verso Paypal, scopriamo che nell'ultimo biennio ha guadagnato quasi 40.000 dollari.

Intendiamoci, unità di misura nettamente inferiori rispetto a quanto avrebbero fruttato le stesse vulnerabilità se applicate per fini fraudolenti. Ma addormentarsi di sera sapendo di non aver commesso alcun reato e, anzi, aver aiutato l'intero mondo informatico rendendolo "un posto migliore" (come cita il motto di HackerOne) è una sensazione a cui un "hacker etico" o "White Hat" non rinuncia per nulla al mondo.

Per le aziende certamente è un segno di grandissima professionalità (oltre che un risparmio economico enorme) avere un programma di bounty pubblico. Insomma, da piattaforme di questo tipo ci guadagnano davvero tutti.


Discaimer: Ogni articolo di questo blog è stato integralmente scritto dall'autore. Il contenuto è completamente originale e la riproduzione, anche parziale, è vietata salvo autorizzazione.