XenData Cloud File Gateway is software that runs on a Windows Server 2016 or 2012 R2 operating system and provides file-based access to Microsoft Azure Blob Storage. It allows your existing file-based applications and workflows to use cloud object storage without need for modification.

Yes, Cloud File Gateway software can be installed on either an Azure VM or an on-premises Windows server.

The XenData gateway software takes control of a logical disk volume on the on-premises server or the Azure VM and this is used to cache frequently accessed files. Policies are defined that can provide highly granular optimizations of the cache. You can set different retention rules for different file types and different folders. For example, specific file types in specific folders may be written to the cloud and also held on disk cache for a week after written or last read; whereas others may be removed from cache immediately after they are written to the cloud.

By keeping frequently accessed files cached on an on-premises server, you minimize Azure bandwidth charges, minimize the use of your Internet bandwidth and greatly enhance file read performance. When you use premium disk storage on a VM as your cache, you can retain or pre-fetch files to the cache and greatly enhance read performance.

You can also schedule time windows when you can still write to disk cache but the copy to Azure is postponed. This is useful when Internet bandwidth is limited and there are busy times when it is in heavy demand.

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.

A Cloud File Gateway is licensed for a maximum cloud storage capacity. When an application checks for the amount of available space, the gateway returns the amount of licensed space that is available in the cloud.

You can use SMB, 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.

The only limits are those of the Windows operating system that you are using.

Yes. Objects created by 3rd party applications may be imported into a Cloud File Gateway. In the case of Microsoft Azure, Azure Storage Explorer or AzCopy are fully compatible with the Cloud File Gateway.

Yes. Objects held in other clouds may be imported into the Cloud File Gateway file structure, creating a multi-cloud global storage solution.

The Cloud File Gateway is fully compliant with the Microsoft security model. The Windows 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.

Yes. ACLs are persisted as Azure blob metadata for each blob. This capability is especially important when multiple Cloud File Gateways are accessing shared blobs, as it allows you to maintain permissions across a global file system.

The network attached to each Gateway instance, supports standard Windows file locking. However, conventional file locking does not extend to Azure blob storage. A Global File System implemented using two or more Cloud File Gateways uses a different mechanism to avoid conflicts, as addressed in the next Q and A.

When multiple Cloud File Gateways form a Global File System, each gateway has one or more dedicated Azure containers which may be accessed by other gateways. If we consider the simplest case with just two gateways, A and B, gateway A could write a first version of a file in one of its containers. If Gateway B then overwrites the file, a second version will be created in a container under its control. The system may be configured such that this second version is the version that is accessible across the entire Global File System. But the first version stored in the container belonging to gateway A is always retained. This approach combines the ability to have global collaboration and ensures that files uploaded by a specific gateway are always retained.

An Anchor Point is a XenData term for a path prefix added to the files stored in an Azure container or set of containers. This is useful when organizing the Global File System. For example, if you import a file structure that was previously uploaded using AzCopy into a dedicated container and this relates to a project called ‘verde’, you may want to add an Anchor Point such as \verde\ when it appears in the Global File System.

There are two ways to implement Anchor Points: locally or globally. When defined globally, the Anchor Point is recorded within a blob container and it applies to all gateway instances. With a local implementation, the Anchor Point only applies to the file system view for that gateway instance.

No. There is no deduplication or compression.

The volume of files stored in the cloud is unlimited but the disk cache volume is limited to 256 TiB. A single gateway is limited to 2 billion files, no matter whether stored on the disk cache and/or in the cloud.

All data transferred is encrypted using SSL.

Hot and Cool.

Any region that provides blob storage is supported.

The biggest differences between Microsoft’s Azure File Sync and a Global File System implemented with multiple Cloud File Gateways are scalability and associated cost. Azure File Sync uses Azure File Storage, whereas XenData Cloud File Gateways use Azure Blob storage which is much lower in cost. And when it comes to scalability, Azure File Sync has many limitations not present with the XenData alternative. For example, XenData Cloud File Gateways have no practical capacity limits, yet File Sync has end-points capacity limits of only 4TiB.