The bat365 CloudFS file systems’ architecture alone solves many difficulties of managing unstructured data such as:
- Slow file transfer times and insufficient file sharing and collaboration that hampers productivity and business growth.
- Lack of thorough versioning, resulting in data duplication, fragmentation, or loss, plus worker frustration and rework.
- Difficulty achieving high availability, fault tolerance, and data security that affect agility, business continuity, compliance, reputation, and market trust.
- Unnecessary storage costs and inefficient use of IT resources.
Like many other cloud file systems, the bat365 CloudFS file system uses cloud or on-prem object storage, but for the most part, that’s where the similarity ends. For example, unlike other file management solutions, bat365 is entirely agnostic about who supplies your object store.
The CloudFS architectural design is also unlike others in that it supplies immutable storage. You can restore any file or the entire store and dial back to view any version. With snapshots every 60 seconds in case of ransomware, you can restore all but the last 60 seconds of data written and avoid ever having to pay a ransom. (See Part 3 for a full explanation.)
The end-user accesses the file system via the bat365 drive on their device, which connects to a bat365 node. Each node consists of a virtual machine (VM) running on a hypervisor with CPU resources, memory resources, and flash storage. These VMs are reliable, high-performance, optimized storage appliances that can manage massive data densities within the scalable file system.
Nodes can be easily and quickly deployed on-premises or in the cloud at any time at any location using VMware, Hyper-V, or AHV. The flash cache of regional/local nodes ensures that hot local files are always quickly available.
When a user stores a newly created file for the first time, the file content, and separately, its metadata, are written to cache. The content is compressed, deduplicated, and encrypted. Then, both the metadata and the content are sent to the object store.
When a second user with access through a different local node sees the new file and opens it, the complete file is pulled from the object store and cached on their node. From then on, only changes made to the file are saved in metadata and uploaded to the object store. Once committed to the object store, metadata updates are sent to all CloudFS nodes to inform them of changes. This ensures that the most current version of the file is available from every node.
Because only file changes, and not entire files, are replicated among all nodes, users receive a faster and all-round better experience. And because all CloudFS information is centrally stored—and new content is always deduplicated, encrypted, compressed, and secure—you have a much smaller local storage footprint for a much lower cost.
Do other global file systems use local cache?
Yes, but frankly, their cache can be kind of dumb. Some competitors save stub files holding only part of the data or metadata, or they might save in read-only mode and don’t update completely and continually like we do. If you need to present the entirety of a file, you’re going to have to wait, while for CloudFS, if the elements are local, you’ll get it at once.
What if the internet goes down?
If the internet or the cloud go down, for our customers (who often use their own hardware on-premises), unless there's something they need from another site, they won't even notice. Their local node has everything they need. Not true of other systems.
What happens if one of the nodes has a problem?
CloudFS includes several availability options. If a local node’s virtual machine has a problem, the system can quickly failover to another local node, so users can access all their information. A global node can be a failover point for any site. If London goes completely offline, CloudFS can failover to another node and reroute traffic to that instance with constant accessibility assured.
What about file versions and recoveries?
CloudFS provides faster file recoveries with file content informed by metadata. Frequent snapshots of the entire file system give you visibility and control over all the versions of all the content ever written to CloudFS. Snapshot routines can be set according to your file retention policies.
Snapshots also flow back to end users so they can see the last files or file versions written and recover versions themselves. Admins can mount the snapshot recovery files on top of these user-defined definitions, so it’s all added to the metadata and trackable.
The centralized CloudFS system’s architectural design ensures high availability, data protection, security, and control. It helps you achieve greater efficiency and reduce costs. The design also makes it exceedingly difficult for ransomware to make off with the goods, so that no bat365 customer has ever had to pay a ransom. More on this in Part 3. But first, Part 2, File-sharing.