Introduction

In modern cloud infrastructure management, maintaining a balance between high availability, performance, and cost is a perpetual challenge for DevOps engineers and system administrators. While container orchestration tools like Docker Swarm offer an elegant, lightweight alternative to Kubernetes for managing clustered applications, they frequently run into a critical bottleneck: persistent storage.

Standard Docker volumes are isolated to individual nodes. When a container is rescheduled to another node due to a failure or scaling event, its data does not automatically follow. To solve this, teams often resort to traditional Shared File Systems like NFS, GlusterFS, or expensive cloud-managed block storage. However, these solutions either introduce a single point of failure (SPOF), scale poorly, or drain your infrastructure budget rapidly. This article explores a powerful, production-ready, and highly economical alternative: pairing JuiceFS with Backblaze B2 to create a high-performance Persistent Volume system for Docker Swarm.

The Core Challenges of Docker Swarm Storage

Before diving into the solution, it is vital to understand why distributed storage for Docker Swarm is traditionally difficult to implement on a budget:

Data Mobility: Docker Swarm moves containers dynamically across a cluster of nodes. Traditional local volumes cannot sync across instances automatically.
Concurrency: Many enterprise applications require multiple replicas of a container to read and write to the same storage volume simultaneously (ReadWriteMany or RWX capabilities).
Cost Scaling: Standard cloud block storage (like AWS EBS or DigitalOcean Block Storage) cannot be natively attached to multiple nodes at once, forcing teams to use costly managed file storage options.
Operational Complexity: Setting up distributed file systems like Ceph or GlusterFS requires heavy operational overhead, deep expertise, and substantial system resources just to maintain the storage cluster.

What is JuiceFS?

JuiceFS is an open-source, high-performance, cloud-native POSIX file system built on top of Object Storage and a Metadata Engine. By separating data storage from metadata management, JuiceFS achieves the performance of a local file system while leveraging the elasticity and massive scale of object storage.

In a typical JuiceFS architecture:

Data Storage: Files are split into blocks and stored securely within an object storage bucket (e.g., Backblaze B2, AWS S3, or MinIO).
Metadata Storage: File attributes, directory structures, and access control lists are stored in a high-performance database engine such as Redis, PostgreSQL, MySQL, or TiKV.

By offloading the heavy lifting of raw data chunks to ultra-cheap object storage and keeping the file hierarchy in a fast database, JuiceFS delivers sub-millisecond metadata latency alongside massive throughput.

Why Backblaze B2?

While JuiceFS supports almost any cloud object storage provider, Backblaze B2 stands out as the ultimate choice for budget-conscious engineering teams. When compared to the industry giants, Backblaze B2 offers identical reliability and data durability at a fraction of the cost:

Storage Pricing: At approximately $6/TB per month, it is roughly one-fourth the price of Amazon S3 standard storage.
Egress Fees: Backblaze features exceptionally low data egress fees, and downloading data through partner Content Delivery Networks (CDNs) like Cloudflare is often entirely free.
S3 Compatibility: Backblaze B2 provides a fully compliant S3-compatible API, making it seamlessly compatible with JuiceFS out of the box.

Architecture Overview

To implement this setup within a Docker Swarm cluster, we establish three distinct layers:

The Cloud Object Storage Layer: A Backblaze B2 bucket that holds the actual encrypted data blocks.
The Metadata Management Layer: A highly available Redis instance (or a managed database like PostgreSQL) that handles directory structures and file locks. For small-to-medium clusters, a secured, standalone Redis instance with daily backups is highly cost-effective.
The Client Layer: The JuiceFS mount client running on every Docker Swarm manager and worker node, exposing the shared storage as a local directory pathway or via a dedicated Docker volume plugin.

Step-by-Step Deployment Guide

Step 1: Provisioning the Backblaze B2 Bucket

First, log in to your Backblaze account and create a new private bucket. Ensure you generate an Application Key and note down your Key ID, Application Key, and the S3 Endpoint URL corresponding to your bucket\'s region. These credentials will be required by JuiceFS to authenticate and read/write data blocks.

Step 2: Setting up the Metadata Engine

For the purpose of this architecture, we will utilize a Redis instance. You can deploy Redis on a dedicated management node or use an existing highly available database instance. Ensure your Redis instance is password-protected and accessible via a secure network from all nodes within your Docker Swarm cluster.

Step 3: Initializing the JuiceFS File System

Log in to one of your Swarm nodes, install the JuiceFS CLI tool, and execute the following initialization command to format your new file system:

juicefs format 
  --storage s3 
  --bucket https://your-b2-bucket-endpoint 
  --access-key YOUR_B2_KEY_ID 
  --secret-key YOUR_B2_APPLICATION_KEY 
  "redis://:yourpassword@your-redis-host:6379/1" 
  myswarmstorage

This command registers your Backblaze B2 bucket to your Redis metadata engine under the file system name myswarmstorage.

Step 4: Installing the JuiceFS Docker Volume Plugin

To allow Docker Swarm tasks to utilize this storage natively, you must install the official JuiceFS Docker Volume Plugin on every single node within the cluster. Run the following command on all managers and workers:

docker plugin install juicefs/juicefs 
  --grant-all-permissions 
  --alias juicefs

Configure the plugin with your metadata backend connection string so it knows where to fetch file system structures when creating containers:

docker plugin set juicefs META_URL="redis://:yourpassword@your-redis-host:6379/1"

Deploying Services in Docker Swarm

With the plugin running across all cluster nodes, you can now define services in a docker-compose.yml file that seamlessly leverage the shared, low-cost persistent volume. Below is an example configuration for a scalable Nginx deployment sharing data across multiple nodes:

version: "3.8"

services:
  web:
    image: nginx:latest
    deploy:
      replicas: 3
      restart_policy:
        condition: on-failure
    volumes:
      - swarm_shared_data:/usr/share/nginx/html

volumes:
  swarm_shared_data:
    driver: juicefs
    driver_opts:
      vol: myswarmstorage

When you deploy this stack using docker stack deploy -c docker-compose.yml web_cluster, Docker Swarm handles provisioning the volume on whatever node a replica lands on. Because JuiceFS acts as a POSIX file system, all three replicas can safely read and write to the same Backblaze-backed path simultaneously without data corruption.

Performance Optimization and Best Practices

While this architecture is highly economical, performance depends heavily on your caching configuration. Because object storage introduces higher latency than local SSDs, implementing the following best practices is highly recommended for production workloads:

Local Caching: Configure JuiceFS to use local node SSD space for caching frequently accessed blocks (--cache-dir and --cache-size). This allows subsequent reads to achieve bare-metal speeds.
Network Proximity: Always choose a Backblaze B2 data center region that is geographically closest to your cloud provider nodes to minimize network latency.
Metadata Backups: Since your metadata engine controls access to your entire file system, ensure your Redis or database instance is backed up regularly to a separate location. If you lose your metadata engine, your raw data chunks in Backblaze become unreadable.

Conclusion

Building a highly available Docker Swarm cluster does not require a premium cloud budget. By utilizing JuiceFS as a high-performance bridging file system and Backblaze B2 as an ultra-low-cost object storage backend, you can achieve a robust, production-grade ReadWriteMany Persistent Volume solution for pennies on the dollar. This architecture eliminates storage single-points-of-failure, allows seamless horizontal container scaling, and keeps your operational costs completely predictable as your data grows.

Cost-Effective Persistent Storage for Docker Swarm: A Deep Dive into JuiceFS and Backblaze B2