Amazon Web Services has announced that it now offers a new storage gateway appliance (virtual machine image) that can be placed on a customers site. What benefit is this ? It really provides an easy way to integrate local storage or systems with the facility to replicate data to the Amazon Cloud. For example you could add the technology to an existing data center so that it resided between servers and storage so that you could easily start replicating data to Amazon S3.
Note,however,these are actually stored as EBS Volumes. So although users can access data stored in this fashion locally from the gateway, if they wish to access this data directly through AWS they would need to start an EC2 instance and attached the EBS volume. . This in and of itself makes it easier to then integrate S3 stored data with other AWS services (if this is important to you). Note that this is not ‘replacing’ what you already have (ie. “great, I can just use the Cloud”), it is in addition to what you already have.
Firstly lets look at what the requirements are to host the Gateway. These are:
- VMware ESXi hypervisor (v4.1) on a physical machine with at least 7.5GB of RAM
- Four (4) virtual processors assigned to the appliance VM along with 75GB of disk space for the Open Virtual Alliance (OVA) image installation and data.
- A “proper” sized network connection to Amazon.
- iSCSI initiators on either Windows server 2008, Windows 7 or Red Hat Enterprise Linux
(Also note that the Gateway beta is optimised for block write sizes which are more than 4Kb. AWS warns that using smaller I/O sizes are likely to cause overhead which can result in storage space that is effectively ‘lost’. This means that prior to installation there needs to be a check made on the file systems / volumes to ensure they can use the larger allocation sizes).
Firstly we’d like to point out that it’s great to see Amazon adding their own on-premise Cloud Gateway. It’s great to see them competing with the likes of EMC, TwinStrata, and Nasuni. It would have been nice to see NFS or CIFS supported as interfaces, as from our own interactions with customers, we believe that is what customers really want to see, but maybe we can expect to see that added as the Gateway offering matures.
(Differences between iSCSI & NFS: iSCSI and NFS both allow storage access over an IP networking infrastructure. The difference is that iSCSI enables block storage transfer whereas NFS and CIFS transfers files.)
Many customers may find that they already have the capabilities for which they would use the Gateway, such as snapshots, backup and archiving, which is a pretty old, mature and I would expect a little more cost effective mechanism of achieving similar goals. However with that said we can see many use case where, with our own Cloud File Server Appliance where customers will really embrace the Gateway.
So where does the AWS Cloud Gateway end and the SME Cloud Appliance begin ? Well, the first things to understand about the SME Cloud Appliance is that it acts at a layer ‘above’ the storage. It provides a mechanism to unify disparate data sources into one file tree, add unified user access management and permissions, add unified governance and e-compliance, has focus on enabling companies to manage ‘Cloud Sprawl’, and leverages the ability for companies to let staff “bring your own device” (BYOD). In short, as I often say when asked to comment about Storage in general, the response is “it’s all about the App”. Storage in and of itself is not a single source in companies and secondly having things stored is no good unless you have unified, search, logic, control and anytime anywhere access that supports all desktops and all devices. This is what we essentially are bringing to the table with our Cloud File Server Appliance.
To take advantage of the Amazon Cloud Gateway what would be required is for us to connect to the local iSCSI stored data within the Gateway and this is something we will be looking to do in the short term.
by 
