LucidLink is a storage startup that transforms a cloud object store into scale-out stream-able, sharable, block storage. Its a log-structured distributed file system that supports mounting to Windows, Linux or Mac. Marketing buzzwords such as 'cloud volumes', 'data lakes' come to mind - but then built on top of low-cost, highly-scalable object storage. LucidLink offers a metadata service if you will, that provides the file system magic, and you can bring your own object storage.
LucidLink could be used for all kinds of large data sets. For cross-cloud data consumption or to allow legacy applications to consume object storage with the performance as if it was locally attached. It provides a simple solution to host network share data with large datasets of millions of files. You can access your LucidLink namespace from anywhere. It is a true file system that consumes object storage offering things like garbage collection, prefetching, caching, with more advanced features to come.
I wanted to try something. Sending backup copy data directly to local object storage with no Veeam Archive tier, allowing you to use all the existing Veeam features, such as instant file recovery, application-item restore, and instant vm recovery on object storage today. I'm using LucidLink 1.12, Veeam Backup & Replication 3a, and Scality open source project Zenko CloudServer which just celebrated their 1.0 release. This post is quite lengthy, and covers a lot of ground. If you want to skip ahead and just try LucidLink, which takes about 5 minutes to deploy, get started at the LucidLink signup page.
LucidLink is probably a little more sophisticated than needed for use as a backup target. In the next update Veeam will support object natively out of the box anyways. Veeam Backup & Replication 9.5 U4 will have native support for object storage in Archive Tier. But in the mean time I wanted to run a little thought experiment. Just keep in mind that this has not been tested to scale at all, and Veeam backup file merge operations may create quite some I/O load depending on the retention model chosen.
Zenko CloudServer is an open source S3-compatible cloud storage controller, with unified management. The idea behind it is that your data could live anywhere, but can be managed centrally under a single namespace.
Note: If you want, you can use Minio or any other flavor of S3-compatible storage instead. Right now LucidLink offers AWS and the 'Other Cloud' option. Each vendor has their own peculiarities relating to API calls and throttling. Official support for vendors such as Google Cloud Storage Interoperability, Wasabi, Zadara and Cloudian and others is 'coming soon'. However right now the 'Other Cloud' option works fine out of the box for most of these object storage providers.
Deploying Zenko CloudServer
- I'm using the container version of Zenko CloudServer so that means using docker. I'll be using Debian 9 and will install docker from its official repository, which means adding an apt repository source.
apt update apt install apt-transport-https ca-certificates curl gnupg2 software-properties-common curl -fsSL https://download.docker.com/linux/debian/gpg | apt-key add - add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/debian $(lsb_release -cs) stable" apt update && apt install docker-ce
- Now we run the CloudServer container
docker run -d --name cloudserver -p 8000:8000 -e "SCALITY_ACCESS_KEY_ID=accesskey" -e "SCALITY_SECRET_ACCESS_KEY=secretkey" -e "ENDPOINT=s3.huttenga.net" scality/s3server. Be sure to change the access, secret keys. And change the endpoint to whatever dns name you will be using publicly. This will download a compressed container image, which will take up about 300MB on disk. The defaults do not give us the correct API endpoint configuration, or HTTPS security. It would make sense to further modify this setup to allow for growth and scalability. But this should be enough for our experiment.
The next step is to ensure we can access this cloud storage. You should now see some kind of access denied page when browsing to this internally. External access on the public internet requires you to set up port forwarding. For testing you can use the localtunnel.me service to expose the API port publicly, and the CloudBerry Explorer for Amazon S3 to verify storage access.
- You will also need to configure Zenko CloudServer to use SSL. This requires that the
certFilePathssection is updated and certificates are generated. Ideally you would store the config file outside of the container. To edit inside the container you will need to install your editor of choice
apt update && apt install nano.
- You'll notice now that if we try to access Zenko CloudServer with the CloudBerry Explorer that it successfully connects.
Intializing LucidLink Storage
- The next step is to create a LucidLink account. After registering you will be asked to create a domain. This does not affect functionality, but pick something unique, and remember that you cannot change the domain name yourself afterwards.
- Then you create and name your first file space. Selecting Your Storage, and in our case, we will select Other Cloud. HTTP and HTTPS, custom ports and region information is supported. However, since we're using Zenko CloudServer, we already configured the endpoint to have a default region.
After that you need to download and install the LucidLink Client, and then select Initialize in the portal. This will open the client on your machine and ask for the access key and secret key we configured and a shared secret. The shared secret is something you need to keep safe as it is used to encrypt the file system.
Note: Normally you can just initialize the file space via the LucidLink Client user interface. But there may be some cases in which you may need to manually initialize the file space via the command line, which can be done by launching the client daemon with
lucid daemonand running
lucid init-s3with additional parameters.
LucidLink's mount point is located underneath your user or home directory by default. Remember that Mac and Linux flavors of LucidLink are supported too, so you could use Linux Veeam Backup Repository to front-end a LucidLink file system if you like. On Windows, if you want to mount LucidLink to a drive letter you can use the
lucid mount l:commands.
Configuring Veeam Backup & Replication to use LucidLink
- I will not run through how to deploy Veeam Backup & Replication as that is pretty well documented. Once your Veeam Backup Server is deployed, create a new Veeam Backup Repository pointing to the drive letter we mounted earlier. Then we'll create a Backup Copy job pointing to this repository.
Note: Metadata for your LucidLink file system exists locally as well as on the LucidLink servers. The block data is encrypted and is stored directly on your object storage. As LucidLink is a shared log-based file system, it does things like cache data locally, performs garbage collection if data is deleted. You can watch upload progress through the LucidLink Client. Client status data can be accessed programmatically, via an API if necessary, to ensure that connectivity is not terminated until upload is complete. This is useful for situations where you may want to disconnect the drive letter afterwards for security hardening reasons.
Now we'll run a Backup Copy Job, remember this is a very small test environment and my proxy does not have that many resources assigned. As you can see this is a pretty cool way to expose object storage as block. All Veeam restore features work, from instant restore to application-item restore.
As a reminder, this is a small demo of what can be done with LucidLink, however as Veeam will have native object storage support built-in, this may not be the best use case. Think of how powerful it is to turn cheap object storage into shareable, stream-able, primary storage, by simply mounting it to your operating system as if it was another disk in your system. Using LucidLink makes it possible to use existing object storage for very different things.