Abbiamo scritto da poco un articolo su Datacore ma ieri sera (sono a Francoforte per l’SNW Europe) ho avuto l’opportunità di incontrare Christian Marczinke (Director Systems Engineers EMEA). L’altro post è stato molto incentrato sul prodotto ma questa volta ho cercato di indagare un po di più sull’azienda, sulla filosofia e strategia.
Lo storage Hypervisor
Datacore è sul mercato da circa 14 anni e in azienda sono tutti molto orgogliosi di SANSymphony-V (il loro prodotto) e sul fatto che lo stanno proponendo come un software e non come un appliance (hardware e software pacchettizzati insieme). Sono rimasti l’ultimo vendor a farlo, anche Falconstor (che ha una soluzione concettualmente simile) ha iniziato a vendere appliances da qualche tempo.Quando ho domandato perché, mi hanno candidamente risposto: “Noi siamo uno storage hypervisor: quello che VMware è per i server noi lo siamo per lo storage!”
Ho insistito sul rischio di questo approccio (tanti diversi hardware con cui avere a che fare, il rischio che i clienti/parrtner non rispettino le best practices, ecc.) ma loro sono stati altrettanto chiari sul fatto che hanno oltre 20.000 installazione in più di 6000 cliente soddisfatti e fedeli, quindi non vedono perché cambiare (visti i numeri ho fatto fatica a dargli torto e continuare oltre).
Il tiering e il cloud
Recentemente, Datacore ha presentato una nuova feature per l’automatic storace tiering a livello di sub-LUN. Mi hanno mostrato diverse diapositive interessanti sull’argomento, soprattutto sulla granularità (fino a 1MB) e sugli algoritmi che hanno implementato per ottenere il massimo risultato, ma quello che mi ha interessato di più è stato che uno dei tier è il cloud.Infatti, Datacore ha un connettore (basato su un appliance virtuale TwinStrata) capace di muovere dati da e verso diversi cloud storage providers pubblici (es.: Amazon S3 o, in italia, il Cloud storage di Seeweb) attraverso protocolli standard (quindi si potrebbe pensare anche ad un cloud privato implementato su API standard del tipo HTTP RESTful)
L’idea è decisamente buona ma, lo ammetto, l’implementazione ha diversi rischi: si può muovere verso il cloud tutta una LUN o parte di essa ma non è molto chiaro come viene gestita una LUN splittata (parte locale e parte sul cloud) in caso di un problema con la connessione ad internet!
In pratica l’unica via sicura per usare il cloud connector è quella di usarlo senza il tiering e usando lo storage locale solo come una grande disk cache per limitare le latenze della rete...
Leggi l'intero articolo
Nessun commento:
Posta un commento