As you can see the statistics shows where the data for this Volume (or LUN) is located, the “Replay” space is the Snapshot space used, the “Active” space is the changed data since the last snapshot taken (this screenshot was taken a couple of minutes after the latest snapshot).

Feel free to comment and ask question about that!.

Fabio

I take, as an example, Hitachi and its USP-V: they claim that the USP-V can address 247 Petabytes of storage behind it (virtualized and internal), and that the storage can sustain 4 MILLION IOPS!. That’s pretty impressive! (even if you read their SPC-1 Benchmark report and see that with their best config they can reach just 200.000 IOPS but that’s another story).

Well, it’s not so impressive actually

If you do some simple math you can clearly see that 247PB (maximum addressable space) divided by 4.000.000 IOPS (maximum IOPS achieved) give you a mere 0.01521 IOPS per GB, that’s really a NOT impressive.

So, even with the best configuration, best practices followed, best Tier 3 storage virtualized behind it you cannot squeeze the system to its maximum capabilities.

Considering that, I think that Monolithic storage is on a dead end railway, the Scale out approach is surely the way to go in the near future.

o a volte abbiamo dato per scontate alcune nostre conoscenze pregresse, che tanto scontate non sono?

A scanso di equivoci, ecco una piccola lista di termini, che spesso utilizziamo nei nostri articoli, con la relativa spiegazione.

Divido la lista in due parti, una con elementi più basilari (che probabilmente i più conosceranno…) ed una con termini più avanzati.

Prima parte

- Raid

Un sistema che consente di distribuire i dati su un numero di dischi, da 2 in su, ottenendo un aumento di velocità (rispetto ad un disco singolo) ed una ridondanza dei dati che permette la rottura di uno o più dischi senza interrompere l’accesso ai dati. L’insieme dei dischi coinvolti nel sistema RAID viene denominata appunto RAID Group.

- LUN (Logical Unit Number) o Volume

Una partizione di un RAID Group all’interno di uno storage. I due termini sono generalmente utilizzati come sinonimi. In parole povere è una fetta di spazio esposta verso i server che la devono utilizzare.

- SAN (Storage Area Network)

Consiste in una rete di comunicazione verso uno o più storage che consente l’accesso ai dati da parte degli host collegati a tale rete. Il trasferimento dei dati avviene principalmente tramite tecnologie FC e iSCSI.

- HBA (Host Bus Adapter)

Si tratta di una scheda che viene installata a bordo di un server (Host) e permette a quest’ultimo la connessione alla storage area network sia essa FC o iSCSI.

- FC (Fibre Channel) e iSCSI

Sono le due tecnologie più utilizzate per il trasporto dei dati negli storage moderni. Nel primo caso (FC) le comunicazioni passano attraverso cavi in fibra ottica e nella SAN sono necessari switch per il protocollo FC e dal lato host delle HBA FC. Nel secondo caso, l’iSCSI, trasporta i  dati su normali cavi Ethernet attraverso il protocollo IP.

- CNA (Converged Network Adapter)

Si tratta di schede con adattatori (prese) ethernet che supportano il protocollo FCoE (FC over ethernet), oltre al traffico TCP/IP (anche iSCSI). Tali adattatori possono essere embedded su server o montati tramite scheda aggiuntiva.

Seconda parte

- Wide Striping

E’ la caratteristica che indica l’utilizzo di un Raid Group diverso da quello classico (statico), permettendo di coinvolgere tutti i dischi di uno storage (o anche una parte) sotto un unico raggruppamento flessibile, all’interno del quale potrò gestire diversi tipi di raid a seconda della necessità di ogni LUN. Il raggruppamento di dischi è estensibile, basterà aggiungere i dischi al sistema e otterremo un incremento di spazio e anche di velocità.

- Thin Provisioning

Consiste nel mostrare agli host lo spazio disco di cui hanno bisogno pur non utilizzando più spazio di quello effettivamente scritto.

Banalmente una lun da 1000GB mappata ad un host che ne utilizza solo 50 occuperà a livello dello storage, solo 50GB. Potremo in questo modo risparmiare sul numero dei dischi da acquistare, sapendo che all’occorrenza ne potremo aggiungere altri a caldo.

- Deduplication

Negli storage di nuova generazione è possibile risparmiare spazio su disco eliminando i blocchi ridondati. In pratica i blocchi identici all’interno di un volume vengono ridotti ad uno soltanto.

- Snapshot

E’ l’immagine di un volume fermata in un determinato momento.

Di solito tale imagine viene poi montata read-only per backup o Disaster Recovery del suddetto volume.

- Tiered Storage

Si intende la possibilità di avere più livelli di velocità per l’accesso ai dati. Più semplicemente se ho dischi di diversa velocità (FC piuttosto che SAS piuttosto che SATA, magari SSD!) potrò far risiedere i miei dati in posti differenti a seconda della performance richiesta. Alcuni Storage moderni permettono la migrazione dei dati da un livello all’altro in maniera automatica, in base al numero di accessi effettuati. Ad essere migrati possono essere i singoli file, le lun o come nel caso di Compellent, i singoli blocchi, i quali, se non acceduti per tanto tempo, verranno spostati su supporti più lenti, mentre al contrario i più utilizzati potranno arrivare ai dischi più veloci e magari, nelle implementazioni più performanti, alla parte di disco più veloce (tracce esterne). Risulta evidente che ne deriva una ottimizzazione delle risorse (non ho più bisogno di avere tanti dischi veloci/costosi) ed un guadagno di performance.

- Boot from SAN

Consiste nella possibilità di installare il sistema operativo di un server direttamente su un volume contenuto in una SAN (Storage Area Network) collegata in FC o iSCSI ed esguire il boot da quest’ultima. Potremo in questo modo avere host senza dischi interni con notevoli vantaggi. In primis, in caso di danni gravi alla macchina server, sarà sufficiente sostituirla con una simile e il sistema potrà ritornare in funzione in pochi minuti (non dobbiamo riinstallare nulla!). Secondo, possiamo in certi casi godere di un incremento della velocità, se i dischi del nostro storage sono più veloci di quelli interni (difficilmente troviamo su un host dischi interni FC a 15k giri in stripe ). Infine, mano al portafoglio, se possediamo già una SAN, possiamo risparmiare i soldi di dischi interni e schede raid aggiuntive (al massimo dovremo acquistare una HBA).

Spero di aver chiarito qualche concetto per rendere più semplici le vostre letture future.

Ciao.

Dario

I’d like to jot down my point of view, just to be sure it does not go with the wind…

It’s frankly undeniable that present days are quite hard days for Sun, their customers and their parters too: administrative andorganizational procedures are all tripped up and it takes a lot of patience to bear with as long as the rearrangement will be completed (hopefully by the end of current year’s first half).

My intervention dealt with this uncertainity phase as well as with the future we all eagerly await for.

Firstly: transaction

A smooth transaction would be of great help for all: customers, partners and Oracle-Sun itself!

By now Oracle shouldn’t impose its own margin nor sales policy, because former Sun ecosystem inhabitants are used to deal with hardware, not software nor appliances (I namely termed Exadata appliances as washing machines)

Sun products although being valuable, do not sport any truly superior value than HP, Dell or IBM products, to justify an higher price. To keep your competitive position Oracle/Sun must fairly price their product and process the offers in a timely manner (Oracle/Sun bureaucracy is reminescent of Ministry of Budget’s)

It’s easy to see potential customers flee from a potential supplier not able to offer a right price in a timely fashion.

One more bad thing to do is to abruptly cut a business partnership (I’m thinking about HDS) without offering any option to the resellers. Don’t tell me they thought Exadata were a suitable surrogate for a real storage..

Then: future.

Any reflections about future are quite hard to ponder, I hope that Oracle (along with a couple of former-Sun manager) can give us the right directions.

At present I can just confirm dubts that customers and resellers are raising about hardware strategies being defective, to say the least. Let’s get back to the washing-machines (Exadata appliances), Oracle will offer a turnkey product, hw, sw and services.

A customer who buying that solution should simply not care about what’s inside.

Exadata and similar products are software focussed: they do not use the best hardware, what the hardware lacks for is made up by sw, i.e. ASM (in a coarse way: Oracle volume manager) overcomes disks breakdown by means of sw

data protection. So? It’s easy to comprehend, to build appliances you need nothing more than second-class hardware, anonymous servers with taiwanese mobos. Just take a look at any appliance you have, surely the hardware is not from a major vendor nor a last generation one (it would cost too much and grant a too low margin), surely is what you can call a volume server.

Volume servers or high-performance enterprise-class servers?

When my dearest bought our last washing-machine didn’t care about CPUs, RAM, PCI bus, connectivity and so on, instead she asked about cycles, about the closest support center (you know, with 2 pre-school aged children this is mission critical), usability, power consumption and so on. I bet customers do ask similar questions when buying an Exadata: why should they care about what’s inside? HP, Sun, Dell hardware? They just trust in Oracle….

Indeed the message Oracle delivered is blurred. Do they want to manifacture/sell volume servers (good for washing-machines) or higher priced as well higher-performance value servers? Do they want to sell Oracle branded volume hardware, as a resell I can agree, but their price must be fair (low).

I can agree about selling high priced value servers too, but in this case the hardware must sport top notch qualities to allow a higher price margin.

At the partner event I gave the iPhone example: either you sell the best cell-phone in the market, the product everybody wants, the coolest, most efficient, best engineered, or you just are one among many! Price depends on quality (or better, perceived quality) not just on the company brand. When Apple entered the cell-phones arena they offered the best phone

in the market, competing with RIM (CISCO ?) but leaving well behind Nokia (HP), Motorola (Dell) and Samsung (IBM) scratching each other’s eyes out in the ordinary cell-phones market.

You can see people queuing to buy iPhones whithout a single cent rebate, most of the times with carrier tying contracts, just because that phone is perceived to be the best, because you can find a very wide software offer, because of its useability, or because it does (almost) everything and well.

Oracle, please tell us what side are you on, volume hardware appliances or value (higher margin) servers (why not, to build value appliances upon)?

Vorrei scrivere anche in questo post quello che penso in modo da essere sicuro che il messaggio rimanga da qualche parte.

Il momento di Sun è molto difficile sia per i clienti che per i partner (inutile negarlo): le procedure amministrative e organizzative sono tutte sconquassate ed è necessaria molta pazienza per adattarsi ad un processo che -speriamo- finirà entro la metà di quest’anno.

L’obiettivo del  mio intervento è stato duplice il primo legato direttamente a questo periodo di transizione, il secondo al futuro.

La Transizione

Una transizione fluida e senza troppe rigidità da parte di Oracle aiuterebbe tutti: i clienti, i partner e l’azienda stessa! Imporre gli standard di marginalità e le relative politiche di vendita del software in questo momento è, quantomeno, poco furbo visto che la maggioranza dei commerciali e dei clienti Sun sono abituati a parlare di ferro e non di software o elettrodomestici (all’intervento le ho definite lavatrici ma la traduzione giusta è appliances, parlo dell’Exadata per intenderci).

Purtroppo i prodotti Sun, per quanto validi, non hanno un valore così tanto superiore di quello di HP, Dell o IBM per giustificare un prezzo più alto e quindi, per rimanere sul mercato, è necessario avere un prezzo adeguato e in tempi rapidi (la burocrazia di Oracle/Sun è paragonabile a quella di un ministero!).

Quindi, adesso, serve il prezzo e serve subito se no il cliente compra comunque, compra altro (magari dallo stesso rivenditore) e Sun è l’unica a rimetterci perchè perde un cliente.

Sarebbe da aggiungere anche che non si dovrebbero tagliare linee di business come quelle HDS senza dare alternative a chi vende ma cosa vuoi? invece di vendere uno storage si può proporre al cliente un Exadata… o no? (non mi sono trattenuto, )

Il Futuro

Per il futuro è tutto più complicato ma spero che Oracle (più qualche povero manager ereditato da Sun) saprà darci le giuste indicazioni. Per ora posso confermare i dubbi di tutti, clienti e rivenditori, sul fatto che la strategia lato hardware è un pò lacunosa.

La questione delle lavatrici (Appliances/Exadata) è abbastanza chiara. In questo caso la Oracle proporrà una soluzioni chiavi in mano fatta di HW, SW e servizi. Il cliente compra una soluzione e, secondo me, cosa c’è dentro il rack non è importante.

L’exadata, e tutte le altre lavatrici, non funzionano sul concetto di avere il miglior hardware ma su un sistema ingegnerizzato come una unica soluzione dove quello che non viene garantito dall’hardware viene assicurato dal software!

Un esempio? l’ASM (banalmente: il volume manager di Oracle): chi se ne frega se i dischi si rompono? ASM ha tutti i meccanismi per proteggere i dati e risolvere i problemi senza fermare i sistemi… e lo stesso vale per le CPU o altre componenti del sistema: esistono software che garantiscono la qualità e la continuità del servizio.

Quindi? quindi è semplice: per fare le appliances basta dell’hardware di serie B. Server anonimi con motherboard taiwanesi. Lo standard degli appliances è questo: basta guardare ogni appliance che avete in azienda e vedere come sono fatti o da dove vengono…. non sarà quasi mai un server dell’ultima generazione prodotto da un vendor principale (perchè costa troppo e abbassa i margini) sarà, come di solito viene definito, un server a volume.

Server a volume o server di qualità superiore?

già, perchè quando mia moglie ha comprato l’ultima lavatrice non ha chiesto che CPU c’era, quanta e quale RAM, quanti PCI, quale connettività, ecc. ma a chiesto che programmi c’erano (intendo, programmi per lavare i panni ), dove era il punto di assistenza più vicino (la lavatrice, se hai figli piccoli, è mission critical), se era facile da usare, meccanismo di carico dei dati/panni, tempi di lavaggio, consumi elettrici e così via?

Scommetto che i clienti fanno domande simili quando comprano un Exadata, cosa gli frega se dentro c’è un HW HP, Sun o Dell? in fondo loro si devono comunque fidare di Oracle… o no?

Quindi il messaggio di Oracle è confuso: Vuole produrre server a volume da mettere nelle lavatrici o server a valore che costano di più ma danno di più?

A me va bene vendere dei server a volume marchiati Oracle ma devono comunque costare poco. Se no va bene anche vendere dei server a valore ma allora devono avere delle qualità di eccellenza per permettere di fare il margine!

L’esempio che ho portato durante il mio intervento è quello dell’iPhone: o hai il miglior telefono del mercato, quello che tutti vogliono, quello ingegnerizzato meglio, quello più bello ed efficiente oppure sei come tutti gli altri!

Il prezzo è in funzione della qualità (o della qualità percepita) e non del solo marchio. Quando Apple è entrata nel mercato dei cellulari lo ha fatto con il miglior telefono del mercato, certo, in competizione con RIM (CISCO?) ma ha lasciato i vari Nokia (HP), Motorola (Dell) e Samsung (IBM) a scannarsi per i telefoni “normali”.

La gente fa la fila per comprare gli iPhone senza un euro di sconto, spesso con contratti capestro, solo perchè è il massimo o forse perhè è supportato dai software vendor, perchè è semplice da usare, perchè fa tutto e lo fa bene.

Quindi la Oracle ci deve dire se vuole fare solo gli appliances o vuole fare dell’hardware di valore (ad alto margine) su cui basare anche i suoi appliances.

Probabilmente, come per sua stessa ammisione, chi scrive quel blog non conosce molto bene lo storage Compellent e magari c’è bisogno di una spiegazione per capire meglio come è possibile raggiungere certi risultati.

Vorrei dire innanzitutto che non conosco l’ambiente di questa particolare trattativa/progetto, ma sono un rivenditore Compellent e lavoro ogni giorno per configurare sistemi.

Prima di tutto noi usiamo il 99mo percentile (come suggerito da Compellent) e non il 95mo. In più consideriamo 177 IOPS e non 220 IOPS per i dischi a 15000 Giri. Utilizziamo inoltre documenti Compellent interni per fare delle configurazioni adeguate. Compellent è davvero (quasi troppo) pignola nella raccolta dei dati del cliente (iops, spazio, latenze, n. di server coinvolti, tipo di carico…etc), quindi mi sembra strano quello che hai scritto.

Compellent, diversamente da NetApp, fornisce Fast Track, Data Progression e Dynamic Block Cache, queste funzionalità aiutano ad ottenere una maggiore performance con un minore impiego di risorse rispetto ai concorrenti. Utilizzandole assieme è possibile raggiungere numeri davvero impressionanti!

Seguimi in questi calcoli: 11 dischi attivi (supponendo che un cassetto con 12 dischi ne abbia uno di spare), raggiungono circa 2000 IOPS ma:

Fast Track

è la capacità di scrivere dati sulla porzione più veloce dei dischi (tracce esterne, circa il 20% dello spazio disco) e ottenere più IOPS e meno latenza.

Se puoi scrivere/leggere dati sulle tracce esterne puoi guadagnare, in pratica, qualcosa come il 15/30% di miglioramento delle performance con una notevole diminuzione della latenza dei tuoi dischi (l’effettivo vantaggio dipende dal numero di server e dalla dispersione delle scritture).

In questo caso Il nuovo totale sarebbe di 2000+20% = 2400 IOPS.

Data Progression

è l’automated tiered storage (non importa cosa tu o la tua compagnia ne pensi ma, se ben implementato, permette un notevole vantaggio). Data Progression, grazie a Fast Track, può lavorare anche su un solo tipo di dischi!

Quindi puoi scrivere dati in Raid10 sulle tracce più veloci e poi farli migrare, secondo politiche e profili, verso Raid5/6 in altre parti del disco.

Con altri produttori devi scegliere in anticipo il tipo di Raid (Raid5 o 6 per risparmiare spazio, Raid10 per avere migliori performance, ma non entrambe sullo stesso volume!).

Non aumentiamo in questo modo le IOPS ma, di sicuro, non le peggioriamo per effetto della scelta di un particolare Raid.

Dynamic Block Cache

La cache di Compellent è piccola (512MB per le scritture in mirror e 3GB a controller per le letture) ma è davvero flessibile e intelligente!

Per ogni LUN puoi scegliere il comportamento della cache e la grandezza del blocco varia dinamicamente tra 2KB e 256KB, significa che il controller alloca lo spazio necessario e non uno prefissato. Nel mondo reale significa che hai più spazio e flessibilità nel gestire i flussi I/O rispetto all’utilizzo di blocchi prefissati.

Spero di aver chiarito al meglio perchè Compellent propone meno dischi dei concorrenti nella maggior parte dei casi.

Sorry to see blog posts like this one.

I like your blog and often I read it but, this time I think you have done wrong calculations and the result isn’t very good.

Probably, as per admission, you don’t know very well Compellent’s stuff and you need some help to better understand how it is possible to achieve similar results.

I would like to say in advance that I don’t know this particular deal/customer environment but I’m a Compellent reseller and I work every day to configure systems.

First of all I use 99th and not 95th percentile (Compellent suggests it to me), second I use 177 IOPS per second and not 220 IOPS per second on 15K rpm disks. We are using internal Compellent documents to do the right sizing to be sure to do the right configurations. Compellent is very, very, very – sometimes too picky- in customers data collections (iops, space, latencies, # of servers involved, type of workload and so on) so it seems very strange to me what you are writing.

Compellent, opposed to NetApp, has Fast Track, Data Progression and dynamic block cache and those help to achieve more performance with less resources than competitors, these features works all together to deliver, some time, awesome numbers!

Follow me with my calculations: 11 active disks (I suppose that 12 disks tray means 1 spare) deliver near 2000 raw IOPS but:

Fast Track

it is the ability to write data on the fastest portion of the disk (external tracks, about 20% of the disk space) and obtain more IOPS and less latency (NetApp hasn’t this feature).

If you can read/write data on external tracks you will gain, in practice, something like 15/30% of better performance and very low latencies from your disks (the advantage depends by number of servers and dispersion of writes).

the new total is 2000+20% = 2400 IOPS.

DataProgression

It is automated tiered storage (its not important what you or your company think about it but, if it is well implemented, it gives very useful advantages). Data Progression works on a single tier of disks too also thanks to Fast Track!

So you can write data in RAID10 on Fastest tracks and then they will be migrated according to policies/profiles to RAID5/6 in other portions of disks.

With NetApp you need to choose in advance the type of RAID (RAID 4 or DP to save space or RAID10 to have better performance, but not all on the same volume!).

We don’t add more IOPS here but there aren’t constraints and less performance due to the use of a certain raid!

Dynamic Block Cache

Compellent’s cache is small (512 MB for mirrored writes and 3GB per controller for reads) but it is very flexible and auto tuned! (BTW, I don’t know the NetApp proposition for the deal you speak about, but if it is a FAS 2040 we are speaking of similar amounts of cache).

You can choose for each LUN the cache behavior and the block is dynamic from 2KB to 256KB, it means that the controller allocates the right space needed and not prefixed blocks. In real world it means that you have more space and flexibility if compared to fixed blocks to manage IO peaks.

I hope I cleared at best why Compellent is proposing less disks than competitors in most of cases.

Doubts, questions or comments? Let me know.

ciao,

Enrico

Fact 1: Oracle has decided, as many expected, not to pursue its partnership with HDS.

This decision is a clear sample of “Oracle-way-of-thinking” and just follows the strategy adopted so far: to keep complete control of the technology stack without having to depend on anyone as regards formulating offerings and maximizing profit.

If Oracle keeps on pushing things like exadata2 or the use of local SSD disks to store parts of a DB, then the storage to the HDS will result just increasingly sophisticated and more or less useless, at least according to our dear Larry!

HDS can definitely record this decision as bad news since Sun was the largest retailer in the world: now the Jap-Americans will be forced to make a quite difficult running start to restore its trading infrastructure, re-establish technical contacts and so on.

Sun customers find themselves with one more bitter pill to swallow: many bought from HDS to have a single supplier and are now in the unenviable situation of having two, they face an even more uncertain future with assistance and professional  services contracts to be renegotiated with HDS rather than with Sun.

The message to Sun customers gets increasingly clear: what was not fully owned by Sun is about to be buried … every allusion to the storage 6000 is not casual!

Needless to say that Sun and HDS competitors are in high spirits: Sun facing hard present times, some storage systems are rather old (the agreement is dated 10 years ago), how much time will take HDS to restructure? More than enough to make any competitor’s mouth water.

Fact 2: IBM continues to push XIV and compares it to the DS8000

I know it’s strange but this must be a strategy, but a quite strange one.

Sure, if you try to ask questions about the performance of a XIV, responses will be among the most imaginative and evasive. Try and write XIV+performance on twitter, then everyone immediately will think about a joke.

I guess that IBM is really developing its “jewel” and maybe when we see the 1.0 2.0 version we will be stunned, who knows….

The more evil ones may think there’s a subtle struggle among IBM internal departments, but really, I think that behind there must be something more … All in all the DS8000 is widely considered as dead (hardware and software architecture are quite  obsolete) and no replacement is planned .

Meanwhile, they just lay themself open to competitors in an almost paradoxical way

Fatto 1: Oracle ha deciso, come molti si aspettavano, di non portare avanti la sua partnership con HDS.

Questa decisione è in piena filosofia Oracle e quindi ricalca senza dubbi la strategia adottata fino ad ora: avere il completo controllo dello stack tecnologico senza dover dipendere da nessuno per formulare l’offerta massimizzando ogni guadagno.

In fondo è ovvio che se Oracle vuole spingere oggetti come exadata2 o usare dischi SSD locali per estendere porzioni del DB, gli storage sofisticati alla HDS sono sempre più inutili o almeno così pensa il buon Larry!!!

Dal punto di vista HDS è sicuramente una brutta notizia perchè Sun era il più grande rivenditore al mondo: ora i Giappo-Americani saranno costretti a fare una rincorsa non da ridere per ripristinare tutti i rapporti commerciali, ristabilire i contatti tecnici e così via.

Dal punto di vista dei clienti Sun è un’altra polpetta amara da dover digerire: molti di questi avevano comprato HDS per avere un solo fornitore senza doversi preoccupare di chi faceva cosa e ora sono nella spiacevole situazione di avere comunque due fornitori e un futuro sicuramente più incerto di prima, anche solo per la questione di dover rinegoziare i contratti di assistenza e servizi professionali con HDS invece che con Sun.

Il messaggio per i clienti Sun è sempre più chiaro: se una cosa non era di completa proprietà di Sun sta per essere sepolta… ogni allusione agli storage 6000 non è casuale!

Dal punto di vista dei Concorrenti di Sun e HDS c’è invece una certa euforia (euforia è un eufemismo ovviamente), il momento non felice di Sun, gli storage che in certi casi sono un po vecchiotti (l’accordo esisteva da 10 anni) e il tempo che HDS ci metterà a riprendere le fila stanno facendo venire l’acquolina in bocca a tutti!!!

Fatto 2: IBM continua a spingere XIV e lo paragona al DS8000

Lo so è strano ma anche questa deve essere una strategia, strana ma pur sempre una strategia.

Certo, se provi a fare domande specifiche sulle performance di un XIV le risposte sono fra le più fantasiose ed evasive del mondo, se provi a scrivere XIV+performance su twitter tutti pensano subito a qualche battuta di spirito, ma si vede che IBM sta sviluppando il suo “gioiellino” e forse quando potremo vedere la versione 1.0 2.0 rimarremo tutti di stucco, chissà.

I più maligni pensano ad una qualche lotta intestina fra le varie divisioni di IBM ma, in verità, penso che dietro ci debba essere qualche cosa di più… in fondo il DS8000 lo danno tutti per morto (architettura hardware e software ormai obsoleti) e non sembra esserci un sostituto a breve.

Però, intanto, stanno porgendo il fianco a i concorrenti in maniera quasi paradossale,

E’ la possibilità di fare il boot (Solaris, Windows 2003/2008, Hyper-V, Linux vari e, ovviamente, VMware ESX) non più da dischi locali, inseriti nel server, bensì da volumi (LUN) nella storage area network.

In una Storage Area Network -FC o iSCSI- correttamente ridondata, l’affidabilità e la velocità saranno al servizio anche del boot e dell’installazione del sistema operativo.

Velocità ed affidabilità sono solo il primo elemento positivo di una soluzione boot from SAN.

Non serve più avere dischi locali negli host.

Diciamocelo, cosa ce ne facevamo di 3 HD da 146/300 GB (2 in mirror e magari 1 di spare), quando comunque il s.o. non occupava mai piu’ di una ventina di GB?

Bene, ci siamo risparmiati 3 dischi ed il relativo controller RAID, una bella sgomitata al TCO, oltre che al minor costo iniziale di acquisto, considerando la razionalizzazione dello spazio disco utilizzato, ed i minori consumi elettrici diretti ed indiretti.

Ma è solo l’inizio.

C’e’ da tener conto che la semplificazione dell’hardware conduce ad una riduzione dei disservizi per rotture di componenti.

Se la S di SAN è uno storage moderno, le sue funzionalità saranno ancora più di ausilio nella gestione della infrastruttura.

Debbo installare una patch critica al s.o.?

Una bella snapshot del volume contenente il s.o. e passa la paura: se la patch si rivela più un problema che un rimedio si può tornare al sistema operativo fotografato appena prima della applicazione della patch.

Posso utilizzare le snapshot come primo livello di backup dei miei server e costruire soluzioni di Disaster Recovery ’spedendole’ ad uno storage nel sito remoto.

Debbo installare un nuovo server con un sistema operativo già presente nella mia server farm?

Se lo storage mi permette di clonare i volumi, ed il mio nuovo server non è troppo diverso da quello che ospita il s.o. già presente, in pochi click sarò pronto per avere una copia del S.O. da un template.

Così facile che sembra di parlare di virtualizzazione,

Già, svincolando l’hardware dal sistema operativo,  in caso di rottura irreparabile di un server potrò sostituirlo in pochi minuti senza richiedere re-installazione.

Non dimentichiamo che altre funzionalità garantite da ogni storage moderno quali il thin provisioning e la deduplica concorrono al risparmio di risorse, ai minori consumi ed ad una semplificazione della gestione.

Ci sarà qualche punto negativo?

No.

C’è solo da ricordare che per fare boot from SAN iSCSI serve una scheda ethernet appropriata, mentre via FC ogni HBA già in uso andrà bene.

Concludendo, non una medicina nuovissima, ma una soluzione finalmente utilizzabile grazie anche alle capacita’ software degli storage moderni.

Giancarlo