XenData Cloud File Gateway software runs on a Windows platform and provides file-based access to Microsoft Azure cloud blob storage. It runs on an Azure virtual machine or an on-premise computer and allows your existing file-based applications and workflows to use Azure blob storage without need for modification. It also manages a dedicated disk volume allowing frequently accessed files to be cached for high performance.
Yes. When installed on-premise, the XenData gateway software takes control of a local logical disk volume; tiering policies are set to define whether files will be copied to Azure blob storage and for how long they will be retained on the local disk. No matter whether a file is stored locally or in the cloud, it resides in the same folder with the same file name and is accessed the same way.
When installed on an Azure VM, the XenData gateway software takes control of an Azure logical disk volume and an Azure blob storage account; configurable storage policies are set to define whether files will be stored on the VM’s disk volume and/or Azure blob storage.
Whether installed on an on-premise computer or an Azure VM, it allows your existing file-based applications and workflows to use Azure blob storage without need for modification. In addition, it allows you to set tiering policies which keep frequently accessed files on a disk volume for best performance.
You can write, read, delete and rename files. The system supports partial file restores. You can create new folders, rename empty folders and delete empty folders.
You can use CIFS, NFS, FTP or local file transfers.
You create a file share as you would for a standard Windows logical drive using the standard Microsoft utilities.
Yes, you can define whether hot or cool storage will be used when setting the tiering policies.
Any region that provides blob storage is supported.
Files are always first written to the managed disk volume. The XenData tiering policies determine which files will be written to blob storage and which will be stored only on the managed disk. For files written to blob storage, retention rules determine how long files will be held on the managed disk after they were written or last read. The user can set different retention rules for different file types and different folders. For example, files in specific folders may be written to blob storage and also held on the disk volume for a week after written or last read; whereas others may be removed from disk immediately after they are written to the blob storage.
No. There is no deduplication or compression.
Yes, you can schedule time windows when you can write to the disk volume but the copy to Azure blob storage is postponed. This is useful for on-premise installations when Internet bandwidth is limited and there are busy times when it is in heavy demand.
The XenData Cloud File Gateway is fully compliant with the Microsoft security model. The Windows VM or physical computer that runs the XenData gateway software may be installed in a domain or Workgroup. The only limitations are those of the Windows operating system.
The disk volume is limited to 256 TB but the volume of content stored on blob storage is unlimited. A single gateway is limited to 2 billion files, no matter whether stored on the disk volume and/or on blob storage.
File size is limited to 256 TB which means there is no practical limit for most applications.
The only limits are those of the Windows operating system that you are using.
It returns the space available on the disk volume. As files are always first written to the disk volume, there must be sufficient space available to write the file.
Yes, you can configure your tiering policies to keep old file version and deleted files on the Azure cloud.
For on-premise installations, all data transferred is encrypted using SSL. In addition, Azure Storage Service Encryption (SSE) for Data at Rest protects your data to meet your organizational security and compliance commitments. With this feature, Azure Storage automatically encrypts your data prior to persisting to storage and decrypts prior to retrieval. The encryption, decryption, and key management are totally transparent to users.