Dave Graham started it all off here with these 2 blog posts :-
http://flickerdown.com/2009/06/moving-from-block-to-cloud-emulex-e3s/
http://flickerdown.com/2009/06/emulex-e3s-fitment/
Chris Evans also riased points on here :-
http://thestoragearchitect.com/2009/06/19/cloud-computing-emulex-enterprise-elastic-storage-e3s/
Emulex have now posted a site for information re this at :-
http://www.emulex.com/solutions/cloud-storage.html
I raised some questions that I'm still not sure I've found the answers to :-
- How does the 'adapter' handle and treat mutable / changing blocks? (eg does it write new block object and retire the old or something more optimised (eg a mini delta block))
- What are the scale targets for the adapter (or groupings of adapters) re qty objects, capacity abstracted, latency, throughput & cache etc?
- What underlying cloud APIs are used? are these 'pluggable / changable'? and can multiple be used at once?
- What specific encryption & KMS system is used?
- How does the adapter work with authentication, authorisation & accounting / billing attributes that may need to be handled re cloud storage?
- What policy mngt framework is used to control the behaviours of the adapters? and how does this relate / compete / cooperate with other policy frameworks (eg Atmos's or Symm FAST etc)?
- Does the adapter maintain the checksum history of the cloud objects written in order to validate that their retrieval matches? if so where is this data stored and how is it protected / made resilient?
- What's the target price point?
- What's the availability date?
- Who will be the first array manufacturer to include this (or similar) as a BE card? and how will that affect technology capability licensing within that array?
- Could this be made to work with other block formats / devices (eg tape emulation)?
- Is this partnering with any other object storage formats (eg XAM, Caringo Castor, EMC Centera etc)?


4 comments: